From nobody Sun Nov 1 09:41: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 7C23A3A07AE for ; Sun, 1 Nov 2020 09:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.206 X-Spam-Level: X-Spam-Status: No, score=0.206 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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 hq7q2VrZx9Rw for ; Sun, 1 Nov 2020 09:41:00 -0800 (PST) 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 8A1D13A0779 for ; Sun, 1 Nov 2020 09:40:59 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id n15so11981277wrq.2 for ; Sun, 01 Nov 2020 09:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=OFCqlV58Rih+UojXg+QPcBwaJnzyVsCQ495F2zpKtUc=; b=G2R9QP5ImzZPgEatQfkjXNvScAolfXq/ad/U/FS+bxm1sgvlvd1iKqlBOkCJqIWGhP loUm/9Clyls0r6gfBSOt7vP8KU+NkguwHVqcY28vCLrZo2ZbXMfi3qUng6yqcYaAfZr3 0ZePQ3pS7KPRdoZEv05ukeXzHhGiNxIGdeh/R0MEVlWUi3go4vlC7m7Oi6VMmbu6rzdj +tLV5FuPXRo+jI6ayOEjSPxKkhJJ70jQC+Gx2Oo9pt1UfgUpVFrGxNE3eUYHPUGV5RT0 SKCEiMkHLOYY/2OsSF38twWouP1lxeHndaqqNdkIb/87C67FccMmEKC1PRN2WLSEodWG vkwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=OFCqlV58Rih+UojXg+QPcBwaJnzyVsCQ495F2zpKtUc=; b=ukYhLkyq7G7JTtpcmGp9ooRVE9lR4GsnFF2n4E9gVRlvQT3mvsGja5cvXL9XG3j/vB NVcWrnGnmULN/AK+IjAYTIzLxHT/GxlK/bZw9q9+40w+5BakHvqmSzJduiY6kb+zGauY sqBgeC01RpmzW6XEaqFiLdbJGnn26X4nRdo5vfqxjN5aZkcDsIunDL4OqzrWqKIUoC5A hCj5w30sK0SvPLq5SiqNy2nvZOVgOONmGx/nqHpLX8PyrX28V3QcTsZWA1nIkhDuIBf2 hHZvYOUuO0DHJOjo0ClKY/dQIGALfRdlFsUiUhv2w13gwqV3SkKnwBMM3kyEnJdwTN69 EiWQ== X-Gm-Message-State: AOAM532Bk44J3huGb8B/Yv5BwMeikQvhGCXG+NGJTtfvjb3xmCGvOh3l yacL6Hd2SGQwQPYeXLJGoVQ= X-Google-Smtp-Source: ABdhPJz/sviKlPSQ8k6D4b2N+oU6rDW1H/gDO5aJ5GeIG/b+vwVdXnKw1LNA2vZMApqSWUuk7grAUw== X-Received: by 2002:a5d:54c8:: with SMTP id x8mr14978138wrv.286.1604252457437; Sun, 01 Nov 2020 09:40:57 -0800 (PST) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id l16sm3794426wrr.83.2020.11.01.09.40.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2020 09:40:56 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Sun, 01 Nov 2020 19:40:54 +0200 From: Yaron Sheffer To: Justin Richer CC: GNAP Mailing List Message-ID: <71D3849B-7052-4CB5-996E-608BD34733FD@gmail.com> Thread-Topic: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) References: <228126C9-2DCD-47D7-8499-EDC5BAD0CD66@mit.edu> In-Reply-To: <228126C9-2DCD-47D7-8499-EDC5BAD0CD66@mit.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3687104455_873818730" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) 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, 01 Nov 2020 17:41: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_3687104455_873818730 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I=E2=80=99m assuming Justin (and the other coauthors, real soon now) will fix the= easy stuff, and will ignore the bits I misunderstood. I am opening issues f= or the bigger things. I have *not* responded inline below, other than with l= inks to issues. =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: Monday, October 19, 2020 at 23:42 To: Yaron Sheffer Cc: GNAP Mailing List Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) =20 Hi Yaron, =20 Thanks for the thorough reading. I agree with the other commenters that Git= Hub issues are a better way to track many of these items. There=E2=80=99s a natura= l threading and separation of discussions, which can get really unwieldy in = a mailing list thread, but you can also explicitly cross-link things. Also, = when changes are made to the document in response to a specific issue, the c= hange set can be linked to the issue that caused them. It also lets people e= ngage on the specific topics that they want.=20 =20 With that in mind, now is the best time for the group to decide on the best= practices for disposition and addressing feedback, and agreeing on when and= how to bring discussion to the list. We have a lot of work ahead of us, and= now is when we need to decide how we=E2=80=99re going to do that work. =20 In the mean time, I=E2=80=99ve commented on each of these inline below. It=E2=80=99s a = lot of writing, and I apologize ahead of time to everyone for that. I also a= pologize in advance if there are cut off sentences or things that don=E2=80=99t ma= ke sense =E2=80=94 there was a lot to discuss here in one go, and I=E2=80=99ve tried not= to leave anything out. I=E2=80=99m hoping that the responses below will offer som= e background and clarity into how we got to what=E2=80=99s there now, so that we c= an find what the right way is forward, even (or especially) where things nee= d to change. Absolutely everything in the 00 draft is up for discussion to d= rive consensus within the working group going forward. And there is a LOT of= discussion for this working group to have still, and I look forward to cont= inuing that discussion in a productive manner. =20 Thanks, =E2=80=94 Justin On Oct 18, 2020, at 3:44 PM, Yaron Sheffer wrote: =20 Hi Justin, all, =20 The draft has undergone major changes since we started the design team, so = I spent some time reviewing it. I only got as far as Sec. 3, and I fully int= end to review the remainder of the document. But I figured since I have so m= any comments, I might as well send out what I have. =20 * General comment: we have dozens, maybe hundreds of variants/options here.= I think we need to define a must-implement subset, or we will never reach i= nteroperability. =20 Completely agree, but please understand that many of these options are pres= ented by the design team as explicit discussion points. In particular, there= are MANY things that are in =E2=80=9CEditor=E2=80=99s Note=E2=80=9D blocks throughout the doc= ument, where the design team saw multiple ways to approach something that we= believed the wider working group should weigh in on. In other words, many o= f what are presented as =E2=80=9Coptions=E2=80=9D aren=E2=80=99t integrated as options within = the protocol itself, but options FOR the protocol to be considered for integ= ration and decision.=20 =20 I=E2=80=99ll also note that the back-and-forth =E2=80=9Cnegotiation=E2=80=9D nature of the pr= otocol allows the different parties to present options to each other at runt= ime (or before) and settle on an overlapping set of functions to enable inte= rop. So the RC can ask for a feature, and the AS can reject it because it is= n=E2=80=99t allowed for a specific request or because the AS doesn=E2=80=99t support it = at all =E2=80=94 in either case, the client doesn=E2=80=99t get what it wants. Even so, = I agree that we will need to have a notion of mandatory to implement within = the protocol in order to facilitate a base level of interoperability, and th= is is currently lacking in the document because I don=E2=80=99t have a good idea o= f what the MTI portions really need to be. As you know, a security protocol = needs to be especially careful not to mandate implementation of an insecure = option for MTI purposes, and that=E2=80=99s a delicate balance the WG is going to = need to settle on. Would you suggest an MTI section be added? OIDC has this,= with several profiles within that section. https://github.com/ietf-wg-gnap/core-protocol/issues/7 =20 * Abstract: the boilerplate text (MUST etc.) usually goes to the Introducti= on, not the Abstract. =20 Thanks, I was led astray by the template I used when I converted to Markdow= n from XML. :) We should move it into a more proper =E2=80=9CIntroduction" section= , which will encompass what=E2=80=99s now labeled =E2=80=9Cprotocol=E2=80=9D in section 1.=20 * 1. "The requesting party operating the software" - I think these actions = are typically performed by the resource owner, who is not necessarily the re= questing party. =20 You=E2=80=99re right, that is not at all clear from the text as written, we can f= ix that. =20 The funny thing is, this is exactly why we separated the requesting party f= rom the resource owner =E2=80=94 they are defined by the actions they take. The re= questing party interacts with the client while the resource owner does the a= pproval. You=E2=80=99re right that in many cases the RO and RQ are the same person= , as this is the core OAuth 2 use case set =E2=80=94 and this is what the text in = question was actually trying to point out.=20 * RS, aka API: we are using the word "API" several times in a more generic = sense (management API, identity API), so maybe replace with "RS, typically a= protected API". =20 Good catch, this is an artifact from a previous version where non-RS items = weren=E2=80=99t described as an API so it was a more safe comparison.=20 =20 (Even so, things like the token management API and request continuation/man= agement now have parity with RS APIs by using access tokens for protection, = so we do need to be more clear/precise about what an =E2=80=9CRS=E2=80=9D exactly is.) * 1.2, "key" is a too generic term in the context of a security protocol. C= an we call it something more specific, maybe "holder identity key"? =20 This isn=E2=80=99t just about a user=E2=80=99s key =E2=80=94 this is primarily a key for the = requesting client software, but it gets used in a number of ways. Keys can b= e bound to client instances and to access tokens, and they can be used to id= entify various parties in the system (including users).=20 =20 It was brought up in the design team meetings that we might not even need t= o define this term, since it=E2=80=99s understood in the wider security space, and= so I=E2=80=99m happy to either take it out or expand it as required. * 1.3.1. "augmented with a hash of the security information" - this is too = implementation-specific, suggest "is cryptographically bound to the security= information". In general, step (7) is way too detailed, and verges on the n= ormative. =20 I=E2=80=99m fine with this suggested rewording. Note though: this is not a generi= c flow, but this sequence is intended to be specific to use of the =E2=80=9Credire= ct=E2=80=9D and =E2=80=9Ccallback (with redirect)=E2=80=9D interaction modes in combination wi= th each other, and thus is specific to the functioning of those elements. * 1.3.2: it is unclear to me what the goal of the user-code interaction is,= in other words what is the threat model. If it's just "second factor, somet= hing you have", then an OTP MFA device would be simpler and offer the same s= ecurity. =20 This is an equivalent function of the OAuth Device Flow: https://tools.ietf= .org/html/rfc8628 =20 It=E2=80=99s not about a second factor for authenticating the user, really, it=E2=80=99= s about facilitating authorization on a secondary device through the use of = a user-typed code to tie the back end and front end together. * 1.3.5 (4): Typically the access token would not be sent once it is expire= d, right? Let's make the example more realistic. =20 The intent is that time has passed between (2) and (4) to allow the token t= o expire =E2=80=94 not that the token is already expired. I initially had a =E2=80=9Csuc= cessful request=E2=80=9D in the middle, but I cut it out as it wasn=E2=80=99t interestin= g to the topic of refreshing a token. I=E2=80=99ll add it back in for clarity.=20 * 2: "OpenID Connect claims request" - why not "identity claims request" (w= hich just happens to be similar to the OpenID request)? =20 Because this is specific to the OpenID Connect Claims query language, which= has inherent limitations on its use. More comments in response to your note= on section 2.8, below. * Never liked the "dolphin" here... If this is listed under "actions", it s= hould be a verb, e.g. "swim". =20 So there=E2=80=99s a (fairly silly) story on why =E2=80=9Cdolphin=E2=80=9D is an example here= and has been an example in several RFC=E2=80=99s I=E2=80=99ve edited, but it=E2=80=99s more a= ppropriately shared over beers when that=E2=80=99s an option again. :) I agree tha= t =E2=80=9Cswim=E2=80=9D is probably less confusing in this specific context though. * 2.1: an array for a single AT vs. an object for multiple ATs? This is ext= remely non-intuitive and probably ugly to code. Also, why should (multiple) = tokens be named if a single token doesn't have to, why not list them in an a= rray instead? =20 I agree that it looks a little odd at first glance, but I=E2=80=99ve coded this i= n a few languages now and on the request side (this section) it is really cl= ear what you=E2=80=99re doing. I think it might be helpful to build up from the pa= rts of this section of the request, which will show the history and decision= process that got us to the syntax that=E2=80=99s there today. Obviously, this isn= =E2=80=99t a statement that it needs to stay this way, but I hope that this will h= elp bring to light the reasoning behind what=E2=80=99s there now so that it can be= explained, refined, or updated as needed. =20 At the lowest level, we=E2=80=99ve got the dimensions for access. OAuth 2 showed = us that =E2=80=9Cscope=E2=80=9D was a useful way for a client to indicate what it wants,= but we=E2=80=99ve found that API designers have used scope to talk about many dif= ferent dimensions of access, all rolled into different scope values. We are = now being explicit about those dimensions, and trying to make those dimensio= ns orthogonal to each other. There is some small amount of fuzziness and pot= ential overlap of interpretation, and ultimately these are all up to the AS/= RS (and the API designer, really) to define: =20 - type: =E2=80=9Cthe kind of API I want to call=E2=80=9D, like OIDC UserInfo or FHIR M= edical Record - datatypes: =E2=80=9Cthe kind of data I want to use at the API=E2=80=9D, like email a= ddresses or office visits - actions: =E2=80=9Cthe kind of actions I want to do on the API=E2=80=9D, like read, o= r write, or make the robot move - locations: =E2=80=9Cthe RSs I want to call the API on=E2=80=9D, like the URL of the = UserInfo Endpoint or a URI for a specific document server cluster - identifier: =E2=80=9Cthe entity I want to do these actions on=E2=80=9D, like the med= ical record ID or bank account number =20 These are all strings or arrays of strings, and they=E2=80=99re meant to be very = specific to the requested access to the API. Specific APIs are likely to add= their own dimensions as well, which can be pretty much anything so long as = the RS can interpret the token that it represents. This is why we have the =E2= =80=9Ctype=E2=80=9D field, which gives us a way to namespace the dimensions.=20 =20 But these dimensions don=E2=80=99t live alone: I=E2=80=99m not going to just ask for =E2=80= =9Cread=E2=80=9D or just =E2=80=9Cmedical record=E2=80=9D, I probably want to ask for =E2=80=9Cread th= e medical record=E2=80=9D. With scopes, we were forced to just put them all in a b= ucket and define awkward semantics for combining them, and then watch things= go awry as an AS protected different APIs with different interpretations of= , for example, =E2=80=9Cemail=E2=80=9D as a scope. So with GNAP, we=E2=80=99ve got a way to co= mbine them into single objects. That lets us create combinations like =E2=80=9Crea= d the medical record=E2=80=9D by combining the =E2=80=9Ctype=E2=80=9D and =E2=80=9Cactions=E2=80=9D fields= into a single object. The =E2=80=9Cpass by reference=E2=80=9D feature allows us to send= a simple string value that is interpreted as if it were one of the objects.= So maybe there=E2=80=99s a =E2=80=9Cfhir-read=E2=80=9D value that means =E2=80=9Cread all available= sections of the fhir medical record of the current user=E2=80=9D. You can think o= f it like a pre-computed object where the client doesn=E2=80=99t have to specify a= ll the details =E2=80=94 and in that way it works almost just like a scope value w= ould.=20 =20 But what if I want read access to the medical history record but ALSO want = update access to the demographic information? We can=E2=80=99t just throw it all o= nto the same object because there are two very distinct requests, but one ac= cess token can reasonably encompass both. So in GNAP we=E2=80=99ve got an array of= objects that allows us to combine these multidimensional requests and have = them all apply to a single access token. Since any of these objects could po= tentially be replaced by a string, this array could have a combination of st= rings or objects, but each item in the array represents the same kind of mul= ti-dimensional request. The =E2=80=9Cscope=E2=80=9D field in OAuth 2 is semantically an = array (even though it=E2=80=99s formatted as a space-separated list of space-free = ascii strings) for exactly this reason: I should be able to ask for multiple= scopes at the same time.=20 =20 The resulting access token is for the total of everything in the array (tha= t=E2=80=99s granted =E2=80=94 of course any of this can be changed by the AS and RO). So= an access token always represents an array of requested access rights, each= access right is an object that describes what=E2=80=99s being requested across se= veral dimensions which are properties of that object in their own syntax. An= access token is a combined collection of access rights, so requesting an ac= cess token requires the structure of an array. And so far, this is inline (b= y design) with what=E2=80=99s in OAuth 2 RAR: https://tools.ietf.org/id/draft-iet= f-oauth-rar-03.html =20 And that brings us to multiple access tokens: Multiple access tokens are re= quested by sending an object which uses labels to mark individual single acc= ess token requests, which as we just saw is an array =E2=80=94 so it=E2=80=99s an object= whose values are all arrays, but specifically arrays that are defined to as= k for a single access token. =20 Why put the labels on these requests? Multiple access tokens need to have n= ames (or labels) so that the client can tell :which: of its access requests = each token maps to. Otherwise, how can a client know which set of resources = it=E2=80=99s supposed to use each token with? The =E2=80=9Clocations=E2=80=9D field (discussed= more below) is for identifying sets of resources, and so that field is not = likely to be the exact set of URLs that the client can use the token at. And= it=E2=80=99s also not guaranteed that all APIs will use =E2=80=9Clocations=E2=80=9D in a way = that=E2=80=99s meaningful to a client =E2=80=94 what if the client wants =E2=80=9Cread=E2=80=9D and = =E2=80=9Cwrite=E2=80=9D access at the same API with different tokens? The =E2=80=9Cread=E2=80=9D tok= en could be long-lived but the =E2=80=9Cwrite=E2=80=9D token short lived, for security p= urposes, but the =E2=80=9Clocations=E2=80=9D would be the same. Additionally, the =E2=80=9Crea= d=E2=80=9D could be limited to GET requests and the =E2=80=9Cwrite=E2=80=9D limited to =E2=80=9CPOST= =E2=80=9D requests, neither of which is really expressed in =E2=80=9Clocations=E2=80=9D. If th= e RC is going to ask for different tokens in a single request, it needs to h= ave a way to differentiate the portions of the response from each other.=20 =20 There are some different syntaxes we could use to make parts of this work, = but these choices tend to have other follow-on effects. Here are a few that = I=E2=80=99ve cycled through in the design of the current proposal: =20 We could ask for multiple access tokens this by having a =E2=80=9Clabel=E2=80=9D field = inside the request for a single access token and then sending an array of si= ngle access token request (so an array of arrays), but then you need to answ= er the question of where in the request to put the label. Should it go in th= e array like the proposed =E2=80=9Ctoken flags=E2=80=9D? Should it go inside one of the = objects in the array? But if it does, what would it mean for multiple object= s in the array to have a =E2=80=9Clabel=E2=80=9D value? Additionally, we=E2=80=99d need to det= ect at the top level whether we had an array of arrays or an array of object= s and strings =E2=80=94 doable, but more prone to weird error cases. (What if an R= C sends an array with one array and one object? We need to detect that now a= nd might end up down the wrong code path before we do, with a naive parser a= nyway.) =20 We could simply require all tokens to be labeled at all times, but I would = argue that the overwhelmingly common use case of a single access token doesn= =E2=80=99t need that kind of overhead because there=E2=80=99s only one set of requested = items that the RC is asking for.=20 =20 We could define single access tokens as an object, with multiple aspects. T= his would potentially let us hang additional fields off of the access token = request alongside the resource list, but it would also mean that we=E2=80=99d have= a degenerate case where you=E2=80=99re defining an object with one member, whose = value is always an array. In other words, this is exactly what the JSON Web = Key Set format does, which I=E2=80=99ve always found clunky. The top level object = doesn=E2=80=99t add anything in the JWKS case, and I=E2=80=99m not seeing how it would a= dd anything here. On the other hand, this would let us use an object for a s= ingle access token and potentially an array for multiple access tokens, but = at some cost to the complexity at the layers below that. =20 None of those ideas lead to a better syntax across the different uses cases= , or that optimize for simplicity in the common use cases. =20 All that is to say that I currently think that what we have is the simplest= and cleanest approach that I=E2=80=99ve seen so far, and I would really love to s= ee if there are any alternatives that offer this same kind of power and clar= ity when exercised the same. I would love to see some fresh ideas on differe= nt ways to approach this. * 2.1.1, "locations": are these really URIs or just URLs? On the other hand= , if these are URIs, why do we need a separate "identifier"? There's too muc= h semantic overlap between "type", "location" and "identifier" - specifying = just "type" may be sufficient. =20 In my implementation, =E2=80=9Clocations=E2=80=9D are actually just Strings that the AS= and RS can dereference to figure out the intended target of the RS. In prac= tice I think these will be URIs that identify the RS (or really, the APIs ho= sted at each RS) in a way that the RC can communicate to the AS and back. It= =E2=80=99s not meant to be an exhaustive list of URLs that the RS will use the tok= en at, since an =E2=80=9CRS=E2=80=9D could have a nearly infinite set of URLs that it pr= otects, depending on the nature of the API. GNAP shouldn=E2=80=99t take a stance o= n the structure of the APIs it protects, much like OAuth didn=E2=80=99t. =20 =E2=80=9Cidentifier" is for an object identifier of some type within the API =E2=80=94 = so while =E2=80=9Clocation=E2=80=9D is more to identify the RS itself, =E2=80=9Cidentifier=E2=80=9D = is to indicate the item at the RS which might not be exposed through any kin= d of URL.=20 =20 =E2=80=9Ctype=E2=80=9D tells you what=E2=80=99s in the rest of the object. The semantics are = shared with OAuth RAR, as mentioned in the note: https://tools.ietf.org/id/d= raft-ietf-oauth-rar-03.html Though, as mentioned in the note, we can=E2=80=99t cle= anly normatively reference RAR directly as RAR needs to exist in an OAuth 2 = world, which has =E2=80=9Cscope=E2=80=9D and =E2=80=9Cresource=E2=80=9D parameters, as well as some = extensions/profiles that use an =E2=80=9Caud=E2=80=9D parameter and other items. We don=E2= =80=99t have those restrictions in GNAP and so the semantics are slightly differ= ent here. In an ideal world, we=E2=80=99d define these in GNAP and RAR would be a = clean back-port of this function to OAuth 2. =20 For a concrete strawman example using OpenID Connect=E2=80=99s userinfo endpoint = with the subject ID 248289761001, we might have something like this: =20 { type: http://openid.net/specs/connect/1.0/userinfo, locations: [ https://server.example.com/userinfo ], identifier: 248289761001 } =20 A more realistic example would be asking for a specific bank account (ident= ifier) at a specific bank (locations) for a specific accounting API (type).=20 =20 Any advice to clarify this intent would be greatly appreciated! =20 =20 https://github.com/ietf-wg-gnap/core-protocol/issues/11 =20 * 2.1.1: it's implied but should be spelled out that the semantics of this = example is the cross product of permissions: I am requesting to read and wri= te and "dolphin" both "metadata" and "images", and that applies to both "loc= ations" - 12 different possible actions. =20 OK, that can be expounded upon here, as that is the intent. Each object is = meant to encompass one fully realized combination of options, which is why t= hey=E2=80=99re presented in an array overall (as talked about above). =20 https://github.com/ietf-wg-gnap/core-protocol/issues/12 =20 * 2.1.2: I don't see the value of the notion of "expansion". It is sufficie= nt that the string is understood by the AS. =20 While I personally agree with your stance, this was from a discussion on th= e list about the nature of the string value that we wanted to capture here.=20 * 2.1.2, "in some situations the value is intended to be seen and understoo= d be the RC developer" - shouldn't we require this value to be always fully = documented by the AS owner, so that the RC knows what it is requesting? =20 For cases when the developer sees it and configures it into the RC code, I = agree. But there are cases (like section 10.3) where things happen more dyna= mically that are also enabled by this functionality.=20 * 2.1.4: why are flags represented as resources? The answer, "this is how O= Auth 2 does it" is not great. =20 The idea is that these are items that alter what the access token that=E2=80=99s = being requested in the =E2=80=9Cresources=E2=80=9D section. It is a sensible way to hang= things together since everything in the array ties to a specific access tok= en. This was a proposed design compromise, and if these flags can fit elsewh= ere then we can do that. https://github.com/ietf-wg-gnap/core-protocol/issues/13 =20 * "the each access tokens" -> each access token. =20 Thanks, got it! * I suggest to extend the editor's note to clarify what is the use case, so= that the group can decide whether split tokens are indeed necessary. =20 I think we should have a more detailed conversation about this potential fe= ature than an editor=E2=80=99s note could reasonably get into. There are a number = of large items (splitting access tokens, directing access tokens to specific= portions of API or RS=E2=80=99s, among others) that I think will be big conversat= ions for the WG, and all the context of these don=E2=80=99t necessarily need to be= documented inside the notes in the document itself.=20 =20 But for discussion and context, this feature was proposed to deal with case= s where the AS might decide to issue several access tokens in any case where= the client requested one, because the AS wants to have restricted audiences= for individual access tokens but the client doesn=E2=80=99t know about the audien= ces ahead of time. I agree that it=E2=80=99s a compelling use case, and it puts se= curity of the protected domains in the hands of the AS where it belongs, but= it would require a client to be smart enough to know what to do with these = tokens downstream, and if OAuth has taught us anything it=E2=80=99s that we can=E2=80=99= t rely on client software to be smart about most anything. :) https://github.com/ietf-wg-gnap/core-protocol/issues/14 =20 * Why is key binding of the access token even optional? =20 Because people still want to use bearer tokens as an option. I think we can= make bound tokens first class citizens in GNAP, and that=E2=80=99s a large reason= behind having consistent key binding approaches instead of having them sepa= rated out (section 8). I think we can even make the =E2=80=9Cdefault=E2=80=9D having the= token bound to the RC=E2=80=99s presented key (and therefore make =E2=80=9Cunbound toke= n=E2=80=9D a flag instead), but I don=E2=80=99t think there would be support in the comm= unity for removing bearer tokens entirely. https://github.com/ietf-wg-gnap/core-protocol/issues/15 =20 * 2.2, "Subject identifiers requested by the RC serve only to identify the = RO in the context of the AS and can't be used as communication channels by t= he RC" - this sounds a bit naive, people will do that anyway. So why is this= a useful statement? (And similarly in 3.4) =20 This inclusion is based roughly off of a similar constraint in OIDC around = subject identifiers: https://openid.net/specs/openid-connect-core-1_0.html#C= laimStability =20 I agree that people will do dumb things anyway, but that=E2=80=99s why we ned to = spell out why it=E2=80=99s dumb here. =20 https://github.com/ietf-wg-gnap/core-protocol/issues/16 =20 * 2.3: what's the benefit of including a URI (URL really) in "display"? Do = we really want the user (RO) to click links provided by the RC? =20 I think we want to give them the option of doing so, yes. It=E2=80=99s up to the = AS to help protect the RO, and that will need to be written up in the securi= ty considerations.=20 =20 This is analogous to =E2=80=9Cclient_uri=E2=80=9D in OAuth Dynamic Registration: https:= //tools.ietf.org/html/rfc7591#section-2 https://github.com/ietf-wg-gnap/core-protocol/issues/17 =20 * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that t= he cert contains the same public key as the cert? =20 I would be ok with the different formats being mutually exclusive somehow. = The AS would need to check that they=E2=80=99re the same and throw an error if not= . But this would also let the RC send over whatever it=E2=80=99s got for its own k= eys every time. https://github.com/ietf-wg-gnap/core-protocol/issues/18 =20 * 2.3, " the AS MUST ensure that the key used to sign the request... is ass= ociated with the instance identifier" - can we be much more specific here, e= .g. the instance_id MUST be byte-identical to the Common Name of the cert? T= his "association" is never clarified, either here or in Sec. 8. =20 No, I don=E2=80=99t think we should be so prescriptive =E2=80=94 for one, it won=E2=80=99t al= ways be a certificate or a JWK (where you might use the Key ID). And for ano= ther, you might want to rotate the key without changing the instance identif= ier. And finally, I don=E2=80=99t think the CN would even be enough since there wi= ll be plenty of cases where you=E2=80=99d be accepting client-supplied keys.=20 =20 The =E2=80=9Cinstance_id=E2=80=9D is an AS-assigned value that it can use to look up in= formation about the instance of RC software making the call. Part of that in= cludes whatever key information is associated with that instance. The =E2=80=9Cass= ociation=E2=80=9D for this kind of thing is up to the AS, and in OAuth we called t= his =E2=80=9Cstatic client registration=E2=80=9D or =E2=80=9Cdynamic client registration=E2=80=9D, d= epending on how it happened. Here, we=E2=80=99re taking a step back from saying th= at =E2=80=9Ca client must be registered=E2=80=9D and instead simply saying that =E2=80=9Cif yo= u see an instance_id, you need to know what key goes along with that and pro= ve that that key is used=E2=80=9D. For many clients, it=E2=80=99s the same net effect as= having a client_id and registering their public key against that client_id = in OAuth 2, but for large swaths of clients that currently fall outside of t= he OAuth world, this is a more flexible overall model. =20 I=E2=80=99d like to understand more about what you=E2=80=99re seeing here with regard t= o the keys, though, especially since this section was restructured several t= imes during the design team discussions and it could be more consistent and = clear.=20 =20 YS: I=E2=80=99m actually fine with this more loose definition. * 2.3.2: allowing to send the key in multiple formats virtually invites sec= urity vulnerabilities. Why is this a good thing? =20 See above, I think this is something we need to talk about more in the grou= p and I=E2=80=99m very open to having better ways present this information. I didn= =E2=80=99t see a harm in having the same key in multiple formats, and JWK itself a= lready allows that with the =E2=80=9Cx5c=E2=80=9D field and related. =20 https://github.com/ietf-wg-gnap/core-protocol/issues/18 (again) =20 * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it he= re? Note that in Sec. 8.3 you are using the full certificate rather than the= fingerprint. =20 It=E2=80=99s more than an identifier, since an identifier could be an arbitrary v= alue =E2=80=94 this is cryptographically derived from a specific certificate. If y= ou=E2=80=99re doing MTLS, the client is still sending the full certificate in the = TLS layer, but this would be a way to call out that certificate in a way tha= t=E2=80=99s tied to the request, without replicating it entirely within the reques= t body. So it=E2=80=99s a way to send the certificate in a more compact fashion th= at you can verify, more than it is a way to identify a certificate whose val= ue you=E2=80=99d need to go look up. * 2.3.2: why are we using raw PEM certificates instead of the JOSE represen= tation? =20 The idea was to make it dead simple for developers. Not everything runs on = JOSE, but JWK is there if you want to use it (including JWK certificate repr= esentations).=20 * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choose = to avoid displaying an arbitrary URI. RC developers must only assume that th= e "name" field will be displayed. =20 I would actually go farther in the security considerations and say that not= even the name is necessarily trusted for display. An RC could claim =E2=80=9CGoog= le Docs=E2=80=9D as its display name, and without other information being displaye= d (like callback URIs or home pages), the RO=E2=80=99s got nothing to go on to fig= ure out if it=E2=80=99s really Google Docs or not.=20 https://github.com/ietf-wg-gnap/core-protocol/issues/17 =20 * 2.3.4, "created just for this request" -> created just for this series of= requests. =20 Got it, thanks.=20 * 2.3.4: I suggest referring to RCs that present unknown keys as "anonymous= RC", and then in 2.4, say that the AS MUST NOT accept any assertions from a= n anonymous RC. =20 I disagree with this =E2=80=94 there are a lot of cases out there where the RC is= n=E2=80=99t =E2=80=9Canonymous=E2=80=9D at all but is still presenting a key that the AS doesn= =E2=80=99t know. And in fact, the RC might be presenting some assertions as to its= own identity that the AS can verify. * 2.4: IMO assertion validation is a MUST, and we should specify what we re= quire for every assertion type we allow. =20 I hear that point, but I=E2=80=99m just not sure we can or even should get into t= hat level of detail.=20 * 2.4: moreover, when possible, the AS MUST match the assertions to the pre= sented sub_id. It may be a hint, but you're not allowed to lie. =20 The reason that they=E2=80=99re a hint is that the client doesn=E2=80=99t really know w= ho the user is yet. So I agree the AS needs to process them, but that doesn=E2= =80=99t mean it has to trust them.=20 * 2.4, "If the identified RQ does not match the RO present at the AS" - I t= hought there are cases where the RQ is different from the RO. Also, I am won= dering why this is a SHOULD, not a MUST. =20 The SHOULD is exactly for that use case where they aren=E2=80=99t the same person= . :) The idea is that the AS would at least be able to detect that the user = that the RC thinks is there is different from the one the AS sees. This migh= t be fine for the AS for multi-person delegation use cases, and the AS can p= rompt the RO during authorization if that=E2=80=99s the case. =20 I can see that this needs to be a lot clearer, and we can work on that text= . * 2.4.1 (but probably applicable to any references): what is the lifetime o= f the reference? As an RC, how long can I assume the user reference is still= valid? =20 That=E2=80=99s up to the AS ultimately. Previous editions of the XYZ Protocol had= lifetimes and other things tied to the reference handles (defined in sectio= n 3.5), but it didn=E2=80=99t seem like anyone actually cared about those parts in= practice. A reference is either going to work, or it won=E2=80=99t, and it could = fail for reasons that have nothing to do with a timeout that the RC can=E2=80=99t = control or have input into. https://github.com/ietf-wg-gnap/core-protocol/issues/19 =20 * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is i= t bundled here? =20 It controls an aspect of how interaction could happen, which is what all of= the fields in this section do.=20 =20 Even though it might look similar, these interaction modes aren=E2=80=99t setting= up things like the OAuth 2 =E2=80=9Cgrant type=E2=80=9D where the combinations of parts= are pre-defined and you=E2=80=99re signaling which combination you=E2=80=99re after rig= ht at the start. Instead, the RC is saying what it can handle throughout the= interaction process. Some of these are things that get the user over to the= AS (redirect, user_code, app), some are for getting the user back after int= eraction (callback), and some are about how interaction can be presented bef= ore the RO is known (preferred_locales). All of these are aspects of the int= eraction process, and it=E2=80=99s the combination of all of these together that s= ay what the client can do. In this model, each of these elements is independ= ently defined, but they are all taken together as a single set of parameters= that can control the means of interaction with the user. So in one way of l= ooking at it, you=E2=80=99re creating the =E2=80=9Cinteraction mode=E2=80=9D by defining all o= f the aspects of that mode at once, including any potential parallel alterna= tives (ie: redirect and app together).=20 =20 The discussion on bundles of interaction elements in the editor=E2=80=99s comment= at the end of 2.5.3 provides an alternative model that would allow the RC t= o define multiple sets of these interactions, so that you could say, for ins= tance, =E2=80=9CI can get you to an arbitrary URL or type a user code but I can=E2=80=99= t do a callback on those =E2=80=94 OR I could get you to an arbitrary URL and also= do a callback on that one=E2=80=9D. This kind of thing would let the AS decide to= give out two different interaction URLs with different expectations on what= to do afterward, as opposed to right now where there is a single expectatio= n of what to do afterward no matter which URL the user followed to get there= .=20 =20 I=E2=80=99ll also note that we removed the term =E2=80=9Ccapability=E2=80=9D from this sectio= n as members of the design team found it confusing as used here since it=E2=80=99s= also used elsewhere in the document. I replaced it with =E2=80=9Cmode=E2=80=9D, but tha= t might have the wrong connotations. I=E2=80=99m happy for suggestions of a better= name than =E2=80=9Cmode=E2=80=9D, but I=E2=80=99m starting to wonder if everything should jus= t be called =E2=80=9Ca thing=E2=80=9D everywhere. :) =20 https://github.com/ietf-wg-gnap/core-protocol/issues/20 =20 * 2.5: the way "callback" is described here is as a capability, not an inte= raction mode. The example only strengthens this view, "callback" is a modifi= er of the "redirect" mode. =20 The =E2=80=9Ccallback=E2=80=9D field defines =E2=80=9Cwhat to do after interaction is done=E2=80=9D= . Therefore, =E2=80=9Ccallback=E2=80=9D does not just modify =E2=80=9Credirect=E2=80=9D, it also pot= entially modifies other any other methods of getting the user in front of th= e AS. When the AS figures out that it=E2=80=99s done with the RO, it follows whate= ver steps the =E2=80=9Ccallback=E2=80=9D defines, regardless of how the user gets there.= So for example, you could have the user present a user code, and then follo= w a callback to push information back into the RC. Or you could have some ki= nd of in-app interaction and still have a callback. =20 Inversely, you could have a redirect :without: a callback, like if the user= scans a QR code on a secondary device but doesn=E2=80=99t come back.=20 * 2.5: "use code" -> user code. =20 Got it, thanks. * 2.5.1: this unnecessary polymorphism IMO just complicates implementations= and prevents extensibility. Instead, I would suggest: redirect: {} redirect:{max_length: 255} =20 I find the pattern of sending an empty object problematic, and we need to a= sk if there are other parameters that would really be sent here.=20 redirect:{max_length: 255, callback: {...}} =20 Again, the =E2=80=9Ccallback=E2=80=9D could be applied to multiple outing options, but = this would be an alternative of including it as noted in the editor=E2=80=99s note= in 2.5.3 about re-using the =E2=80=9Ccallback=E2=80=9D field.=20 * 2.5.2: the "app" option is problematic, as you already note. The RC may n= ot even know if a given URL will result in an application launching. =20 It depends on the nature of app =E2=80=94 it could be a single URL like it is in = many mobile platforms today but it could also be a bundle of other informati= on that can be used to launch the app. I don=E2=80=99t think we=E2=80=99ll be doing any = good by assuming things will continue to be single URLs. * 2.5.2: and shouldn't the RC include a list of supported applications? (Wh= ich would have lovely privacy implications.) =20 I think that=E2=80=99s a reasonable dimension and one of the reasons =E2=80=9Capp=E2=80=9D la= unch should be separate from the =E2=80=9Cnormal=E2=80=9D redirect. I brought this up wi= th some implementors in the financial sector a while ago, and with that grou= p at least there wasn=E2=80=99t a lot of desire for that kind of functionality.=20 =20 I agree that there are some significant privacy implications driving this a= s well.=20 https://github.com/ietf-wg-gnap/core-protocol/issues/21 =20 * 2.5.3: there's a parenthetical discussion on whether the URL is unique. B= ut the nonce parameter implies that the "hash" parameter is unique per reque= st, making this discussion moot. =20 I agree with you, if we have a =E2=80=9Cnonce=E2=80=9D then you don=E2=80=99t necessarily nee= d a unique URL, at least not for security purposes. The editor=E2=80=99s note is t= o point out the inverse that came up in design team discussions, that the =E2=80= =9Cnonce=E2=80=9D is not needed to protect against some of the attacks if you requir= e a unique URL. I would like to see some formal analysis against this featur= e set as we build this out.=20 * 2.5.3: even if we need a different kind of post-interaction "redirect", w= here the RC is not involved, there must be a way to ensure that the RC recei= ves positive (cryptographically protected) confirmation that the authorizati= on was successful. In other words, what we're discussing here is not an RC i= nteraction mode, it is something else, and should probably have a separate p= rotocol element to describe it. =20 I=E2=80=99m on the fence about it being something outside the interaction element= , since it=E2=80=99s a kind of post-interaction method just like =E2=80=9Ccallback=E2=80=9D al= ready defines. I don=E2=80=99t think it makes sense to allow a client to ask for m= ore than one of these at a time, and it could lead to some weird race condit= ions (do I poll if I might get a callback?) and potential security issues (I= polled but then got a callback, is that an injection attack?).=20 * 2.5.3: In the example for "interact" as an array (which I support), the s= econd "redirect" and "user_code" should be independent elements of the array= , not members of an object. This assumes they are truly independent interact= ion modes. =20 No, they are bundled together as the same element in the array on purpose. = This is the client saying =E2=80=9CI can send the user to a short URI or I can dis= play a user code, but I can=E2=80=99t get a callback=E2=80=9D. This is equivalent to the= OAuth 2 device mode of displaying a QR code for the user to scan and giving= them a code to type into a static URL. The QR code is already an arbitrary = URL and so it can use the same mechanism as =E2=80=9Credirect=E2=80=9D. To do what you=E2=80= =99re asking you=E2=80=99d want a three element array.=20 * 2.5.3.1: what does "RQ is present on the request" mean? =20 This is most clear for web server based RC=E2=80=99s: the session that was used t= o send the user outbound needs to be the same that is used when the return c= omes in. It makes less sense with other interaction methods and other client= types, but wherever possible the RC needs to make sure that the user who st= arted the request is =E2=80=9Cstill there=E2=80=9D when the response comes back in the f= ront channel.=20 =20 Is there a better way to say this without making it overly prescriptive? https://github.com/ietf-wg-gnap/core-protocol/issues/22 =20 * 2.5.3.2: typo: HTTP the request. =20 Got it, thanks! * 2.7: this seems to assume a short access token (which implies a bearer to= ken). What if we want to use longer self-contained access tokens containing = full keys? Should we have a separate "grant_id" value instead? =20 I don=E2=80=99t see how this implies a short access token, can you expand on what= you mean by that? The access token value will always be a string, opaque to= the client, so if it=E2=80=99s self contained and has its own keys wrapped inside= of it in some way, that=E2=80=99s fine and would still be enough for the AS to fi= gure out what it means.=20 =20 There previously was the equivalent of a =E2=80=9Cgrant_id=E2=80=9D for exactly this pu= rpose =E2=80=94 it was the =E2=80=9Ctransaction handle=E2=80=9D in previous revisions, and it = was also used for continuation and a number of other functions. That feature= has been phased out in favor of using either unique continuation URIs, acce= ss tokens, or a combination of both for managing the ongoing grant request p= rocess. Having an explicit identifier would be helpful for this specific us= e case, but it=E2=80=99s not needed for the more common use cases anymore. Would i= t be worth bringing it back in? * 2.8: another problem with this stanza is that the RC needs to know a prio= rity that the AS supports it. What happens if the AS doesn't? =20 If the AS doesn=E2=80=99t support this, then it gets ignored and has no effect on= the resulting response. At least, that=E2=80=99s how I think it should go =E2=80=94 we = could also allow the AS to return an error for fields it doesn=E2=80=99t understan= d, but that=E2=80=99s something that needs to be consistent across the protocol in= my opinion. * 2.8: I suggest to move this section into a separate I-D, or at least a se= parate appendix. =20 As stated in the last note in the section, I agree, and in fact don=E2=80=99t thi= nk we should be defining any use of OIDC within the GNAP working group. I th= ink a good exercise would be to build out what an actual OIDC style protocol= would be on top of GNAP, and it=E2=80=99s something I=E2=80=99d like to . The design te= am included this section as a way to show how this type of externally-define= d query language could be incorporated, with all of its limitations and assu= mptions that come with it.=20 * 2.9: it makes sense to bundle extensions and the "capabilities" section i= nto one. =20 While I see the point, the =E2=80=9Ccapabilities=E2=80=9D field is really meant to sign= al specific extensions. It=E2=80=99s really loosely defined right now though, and = I think that we need a lot more concrete applications of the mechanism if we= =E2=80=99re going to keep it. * 2.9: The AS MUST ignore any unknown extension. =20 I=E2=80=99m OK with this stance, but it needs to be consistent throughout the pro= tocol, not just at this level.=20 https://github.com/ietf-wg-gnap/core-protocol/issues/23 =20 * 3: it's confusing that we're using access_token for two different things.= Maybe we could change the RC/AS one to "as_access_token"? =20 I disagree =E2=80=94 I think we=E2=80=99re using them for the same kind of thing. They=E2= =80=99re both access tokens, and they=E2=80=99re used by the client in exactly the sam= e way. The resource being accessed is part of the AS in one case, but the RS= in the other case, but you use the same kind of artifact in both cases to d= o the same kind of thing. I think there=E2=80=99s a lot of power in re-using comp= onents like this instead of inventing something special here. * 3.1: MAY vary *by* request. =20 Got it, thanks! * 3.1: how is the client behavior "deterministic in all cases" - how does t= he RC know whether the AS allows continuation or only allows one request at = a time? =20 If the AS does not include a =E2=80=9Ccontinue=E2=80=9D field in any of its replies, th= en the RC can=E2=80=99t continue it again.=20 * 3.2.1: the "value" of the access token is opaque in some cases (bearer to= ken) but not in others. =20 In what cases would it not be opaque to the client? In all the current bind= ing methods, this value would still be opaque and the RC still has to send t= he token value. * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be prin= table ASCII, 0x20

I=E2=80=99m assuming Justin= (and the other coauthors, real soon now) will fix the easy stuff, and will = ignore the bits I misunderstood. I am opening issues for the bigger things. = I have *not* responded inline below, other than with links to issues.=

 

Th= anks,

=C2=A0=C2=A0=C2=A0=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<= o:p>

 

From: Justin Richer <jricher@mit.edu>
Date: Monday, October 19, 2020 at 23:42
To: Yaron Sheffer <= ;yaronf.ietf@gmail.com>
Cc: GNAP Mailing List <txauth@ietf.o= rg>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol= -00 (first half)

&nb= sp;

Hi Yaron,

 

Thanks for the = thorough reading. I agree with the other commenters that GitHub issues are a= better way to track many of these items. There=E2=80=99s a natural threading and = separation of discussions, which can get really unwieldy in a mailing list t= hread, but you can also explicitly cross-link things. Also, when changes are= made to the document in response to a specific issue, the change set can be= linked to the issue that caused them. It also lets people engage on the spe= cific topics that they want. 

 

With that in mind, now= is the best time for the group to decide on the best practices for disposit= ion and addressing feedback, and agreeing on when and how to bring discussio= n to the list. We have a lot of work ahead of us, and now is when we need to= decide how we=E2=80=99re going to do that work.

 

In the mean ti= me, I=E2=80=99ve commented on each of these inline below. It=E2=80=99s a lot of writing,= and I apologize ahead of time to everyone for that. I also apologize in adv= ance if there are cut off sentences or things that don=E2=80=99t make sense =E2=80=94 th= ere was a lot to discuss here in one go, and I=E2=80=99ve tried not to leave anyth= ing out. I=E2=80=99m hoping that the responses below will offer some background an= d clarity into how we got to what=E2=80=99s there now, so that we can find what th= e right way is forward, even (or especially) where things need to change. Ab= solutely everything in the 00 draft is up for discussion to drive consensus = within the working group going forward. And there is a LOT of discussion for= this working group to have still, and I look forward to continuing that dis= cussion in a productive manner.

=  

Thanks,

 =E2=80=94 Justin



On Oct 18, 2020, at 3:44 PM, Yaron Sheffer= <yaronf.ietf@gmail.com> wr= ote:

 

<= p class=3DMsoNormal>Hi Justin, all,<= /span>

 

The draft has undergone= major changes since we started the design team, so I spent some time review= ing it. I only got as far as Sec. 3, and I fully intend to review the remain= der of the document. But I figured since I have so many comments, I might as= well send out what I have.=

 =

* General comment: we have do= zens, maybe hundreds of variants/options here. I think we need to define a m= ust-implement subset, or we will never reach interoperability.

 

Completely ag= ree, but please understand that many of these options are presented by the d= esign team as explicit discussion points. In particular, there are MANY thin= gs that are in =E2=80=9CEditor=E2=80=99s Note=E2=80=9D blocks throughout the document, where t= he design team saw multiple ways to approach something that we believed the = wider working group should weigh in on. In other words, many of what are pre= sented as =E2=80=9Coptions=E2=80=9D aren=E2=80=99t integrated as options within the protocol i= tself, but options FOR the protocol to be considered for integration and dec= ision. 

 

I=E2=80=99ll also note that the back-and-forth =E2=80=9C= negotiation=E2=80=9D nature of the protocol allows the different parties to presen= t options to each other at runtime (or before) and settle on an overlapping = set of functions to enable interop. So the RC can ask for a feature, and the= AS can reject it because it isn=E2=80=99t allowed for a specific request or becau= se the AS doesn=E2=80=99t support it at all =E2=80=94 in either case, the client doesn=E2=80= =99t get what it wants. Even so, I agree that we will need to have a notion of= mandatory to implement within the protocol in order to facilitate a base le= vel of interoperability, and this is currently lacking in the document becau= se I don=E2=80=99t have a good idea of what the MTI portions really need to be. As= you know, a security protocol needs to be especially careful not to mandate= implementation of an insecure option for MTI purposes, and that=E2=80=99s a delic= ate balance the WG is going to need to settle on. Would you suggest an MTI s= ection be added? OIDC has this, with several profiles within that section.


https://github.com/ietf-wg-gnap/core-protocol= /issues/7

 

* Abstract: the boilerplate text (MUST etc.) usually goes to the Introduct= ion, not the Abstract.

<= /div>

 

<= div>

Thanks, I was led astray by the template I used when = I converted to Markdown from XML. :) We should move it into a more proper =E2=80= =9CIntroduction" section, which will encompass what=E2=80=99s now labeled =E2=80=9Cpr= otocol=E2=80=9D in section 1. 


* 1. "The requesting party operating the soft= ware" - I think these actions are typically performed by the resource o= wner, who is not necessarily the requesting party.

=  

You=E2=80=99re right, that is n= ot at all clear from the text as written, we can fix that.

 

The funny thing is, this is exactly why we separated the requesting party = from the resource owner =E2=80=94 they are defined by the actions they take. The r= equesting party interacts with the client while the resource owner does the = approval. You=E2=80=99re right that in many cases the RO and RQ are the same perso= n, as this is the core OAuth 2 use case set =E2=80=94 and this is what the text in= question was actually trying to point out. 



* RS, aka API: we are using th= e word "API" several times in a more generic sense (management API= , identity API), so maybe replace with "RS, typically a protected API&q= uot;.

 

Good catch, this is an artifact from a previous version where non-RS i= tems weren=E2=80=99t described as an API so it was a more safe comparison. 

 

<= p class=3DMsoNormal>(Even so, things like the token management API and request= continuation/management now have parity with RS APIs by using access tokens= for protection, so we do need to be more clear/precise about what an =E2=80=9CRS=E2= =80=9D exactly is.)



* 1.2, "key" is a too generic term in the context of a= security protocol. Can we call it something more specific, maybe "hold= er identity key"?

<= /div>

 

<= div>

This isn=E2=80=99t just about a user=E2=80=99s key =E2=80=94 this is pr= imarily a key for the requesting client software, but it gets used in a numb= er of ways. Keys can be bound to client instances and to access tokens, and = they can be used to identify various parties in the system (including users)= . 

 

It was brought up in the design team meetings tha= t we might not even need to define this term, since it=E2=80=99s understood in the= wider security space, and so I=E2=80=99m happy to either take it out or expand it= as required.



=

* 1.3.1. "augmented with a hash of the security information&q= uot; - this is too implementation-specific, suggest "is cryptographical= ly bound to the security information". In general, step (7) is way too = detailed, and verges on the normative.

 <= /o:p>

I=E2=80=99m fine with this suggested reword= ing. Note though: this is not a generic flow, but this sequence is intended = to be specific to use of the =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallback (with redirect)=E2= =80=9D interaction modes in combination with each other, and thus is specific to= the functioning of those elements.

<= br>

* 1.3.2: it is unclear to me what the goal o= f the user-code interaction is, in other words what is the threat model. If = it's just "second factor, something you have", then an OTP MFA dev= ice would be simpler and offer the same security.

<= o:p> 

This is an equivalent func= tion of the OAuth Device Flow: https://tools.ietf.org/html/rfc8628

 

It=E2=80=99s not = about a second factor for authenticating the user, really, it=E2=80=99s about faci= litating authorization on a secondary device through the use of a user-typed= code to tie the back end and front end together.



* 1.3.5 (4): Typically the acc= ess token would not be sent once it is expired, right? Let's make the exampl= e more realistic.

=

 

<= p class=3DMsoNormal>The intent is that time has passed between (2) and (4) to = allow the token to expire =E2=80=94 not that the token is already expired. I initi= ally had a =E2=80=9Csuccessful request=E2=80=9D in the middle, but I cut it out as it wa= sn=E2=80=99t interesting to the topic of refreshing a token. I=E2=80=99ll add it back in= for clarity. 



* 2: "OpenID Connect claims request" - why not &qu= ot;identity claims request" (which just happens to be similar to the Op= enID request)?

 

Because this is specific to the OpenID Connect Claims query l= anguage, which has inherent limitations on its use. More comments in respons= e to your note on section 2.8, below.



* Never liked the "dolphin" here= ... If this is listed under "actions", it should be a verb, e.g. &= quot;swim".

<= /div>

 

So there=E2=80=99s a (fairly silly) story on why =E2=80=9Cdolphin=E2=80=9D is= an example here and has been an example in several RFC=E2=80=99s I=E2=80=99ve edited, b= ut it=E2=80=99s more appropriately shared over beers when that=E2=80=99s an option again= . :) I agree that =E2=80=9Cswim=E2=80=9D is probably less confusing in this specific con= text though.



<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

* 2.1: an array for a single AT vs. an object for multiple ATs? Thi= s is extremely non-intuitive and probably ugly to code. Also, why should (mu= ltiple) tokens be named if a single token doesn't have to, why not list them= in an array instead?

 

I agree that it looks a little odd at first glance, bu= t I=E2=80=99ve coded this in a few languages now and on the request side (this sec= tion) it is really clear what you=E2=80=99re doing. I think it might be helpful to= build up from the parts of this section of the request, which will show the= history and decision process that got us to the syntax that=E2=80=99s there today= . Obviously, this isn=E2=80=99t a statement that it needs to stay this way, but I = hope that this will help bring to light the reasoning behind what=E2=80=99s there = now so that it can be explained, refined, or updated as needed.

 

At the lowest level, we=E2=80=99ve got the dimensions for access. OAuth 2 s= howed us that =E2=80=9Cscope=E2=80=9D was a useful way for a client to indicate what it = wants, but we=E2=80=99ve found that API designers have used scope to talk about ma= ny different dimensions of access, all rolled into different scope values. W= e are now being explicit about those dimensions, and trying to make those di= mensions orthogonal to each other. There is some small amount of fuzziness a= nd potential overlap of interpretation, and ultimately these are all up to t= he AS/RS (and the API designer, really) to define:

=

 

 = - type: =E2=80=9Cthe kind of API I want to call=E2=80=9D, like OIDC UserInfo or FHIR Med= ical Record

 - datatypes: =E2= =80=9Cthe kind of data I want to use at the API=E2=80=9D, like email addresses or offi= ce visits

 - actions: =E2=80=9Cth= e kind of actions I want to do on the API=E2=80=9D, like read, or write, or make t= he robot move

 - locations:= =E2=80=9Cthe RSs I want to call the API on=E2=80=9D, like the URL of the UserInfo Endpo= int or a URI for a specific document server cluster

 - identifier: =E2=80=9Cthe entity I want to do these act= ions on=E2=80=9D, like the medical record ID or bank account number

=

 

These are all strings or arrays of strings, and they=E2=80=99re= meant to be very specific to the requested access to the API. Specific APIs= are likely to add their own dimensions as well, which can be pretty much an= ything so long as the RS can interpret the token that it represents. This is= why we have the =E2=80=9Ctype=E2=80=9D field, which gives us a way to namespace the dim= ensions. 

 =

But these dimensions don=E2=80=99t live alone: I= =E2=80=99m not going to just ask for =E2=80=9Cread=E2=80=9D or just =E2=80=9Cmedical record=E2=80=9D, I pr= obably want to ask for =E2=80=9Cread the medical record=E2=80=9D. With scopes, we were f= orced to just put them all in a bucket and define awkward semantics for comb= ining them, and then watch things go awry as an AS protected different APIs = with different interpretations of, for example, =E2=80=9Cemail=E2=80=9D as a scope. So w= ith GNAP, we=E2=80=99ve got a way to combine them into single objects. That= lets us create combinations like =E2=80=9Cread the medical record=E2=80=9D by combining= the =E2=80=9Ctype=E2=80=9D and =E2=80=9Cactions=E2=80=9D fields into a single object. The =E2=80=9Cpass b= y reference=E2=80=9D feature allows us to send a simple string value that i= s interpreted as if it were one of the objects. So maybe there=E2=80=99s a =E2=80=9Cfhir= -read=E2=80=9D value that means =E2=80=9Cread all available sections of the fhir medical= record of the current user=E2=80=9D. You can think of it like a pre-computed obje= ct where the client doesn=E2=80=99t have to specify all the details =E2=80=94 and in tha= t way it works almost just like a scope value would. 

 

But what if I want read access to the medical history record but ALSO want= update access to the demographic information? We can=E2=80=99t just throw it all = onto the same object because there are two very distinct requests, but one a= ccess token can reasonably encompass both. So in GNAP we=E2=80=99ve got an array of objects that allows us to combine these multidimensional = requests and have them all apply to a single access token. Since any of thes= e objects could potentially be replaced by a string, this array could have a= combination of strings or objects, but each item in the array represents th= e same kind of multi-dimensional request. The =E2=80=9Cscope=E2=80=9D field in OAuth 2 i= s semantically an array (even though it=E2=80=99s formatted as a space-separated l= ist of space-free ascii strings) for exactly this reason: I should be able t= o ask for multiple scopes at the same time. 

<= p class=3DMsoNormal> 

The res= ulting access token is for the total of everything in the array (that=E2=80=99s gr= anted =E2=80=94 of course any of this can be changed by the AS and RO). So an acce= ss token always represents an array of requested access rights, = each access right is an object that describes what=E2=80=99s being req= uested across several dimensions which are properties of that object = in their own syntax. An access token is a combined collection of access righ= ts, so requesting an access token requires the structure of an array.= And so far, this is inline (by design) with what=E2=80=99s in OAuth 2 RAR:  = https://too= ls.ietf.org/id/draft-ietf-oauth-rar-03.html

 

And that = brings us to multiple access tokens: Multiple access tokens are requested by= sending an object which uses labels to mark individual singl= e access token requests, which as we just saw is an array&nb= sp;=E2=80=94 so it=E2=80=99s an object whose values are all arrays, but specifica= lly arrays that are defined to ask for a single access token.

 

Why put the labels on these requests? Multiple access tokens nee= d to have names (or labels) so that the client can tell :which: of its acces= s requests each token maps to. Otherwise, how can a client know which set of= resources it=E2=80=99s supposed to use each token with? The =E2=80=9Clocations=E2=80=9D field= (discussed more below) is for identifying sets of resources, and so that fi= eld is not likely to be the exact set of URLs that the client can use the to= ken at. And it=E2=80=99s also not guaranteed that all APIs will use =E2=80=9Clocations=E2=80= =9D in a way that=E2=80=99s meaningful to a client =E2=80=94 what if the client wants =E2=80=9Cr= ead=E2=80=9D and =E2=80=9Cwrite=E2=80=9D access at the same API with different tokens? The =E2=80=9C= read=E2=80=9D token could be long-lived but the =E2=80=9Cwrite=E2=80=9D token short lived, for= security purposes, but the =E2=80=9Clocations=E2=80=9D would be the same. Additionally,= the =E2=80=9Cread=E2=80=9D could be limited to GET requests and the =E2=80=9Cwrite=E2=80=9D limited= to =E2=80=9CPOST=E2=80=9D requests, neither of which is really expressed in =E2=80=9Clocation= s=E2=80=9D. If the RC is going to ask for different tokens in a single request, it= needs to have a way to differentiate the portions of the response from each= other. 

 <= /p>

There are some different syntaxes we could = use to make parts of this work, but these choices tend to have other follow-= on effects. Here are a few that I=E2=80=99ve cycled through in the design of the c= urrent proposal:

 

We could ask for multiple access tokens = this by having a =E2=80=9Clabel=E2=80=9D field inside the request for a single access to= ken and then sending an array of single access token request (so an array= of arrays), but then you need to answer the question of where in the re= quest to put the label. Should it go in the array like the proposed =E2=80=9Ctoken= flags=E2=80=9D? Should it go inside one of the objects in the array? But if it do= es, what would it mean for multiple objects in the array to have a =E2=80=9Clabel=E2= =80=9D value? Additionally, we=E2=80=99d need to detect at the top level whether we ha= d an array of arrays or an array of objects and strings =E2=80=94 doable, but more= prone to weird error cases. (What if an RC sends an array with one array an= d one object? We need to detect that now and might end up down the wrong cod= e path before we do, with a naive parser anyway.)

<= p class=3DMsoNormal> 

We coul= d simply require all tokens to be labeled at all times, but I would argue th= at the overwhelmingly common use case of a single access token doesn=E2=80=99t nee= d that kind of overhead because there=E2=80=99s only one set of requested items th= at the RC is asking for. 

<= o:p> 

We could define single acc= ess tokens as an object, with multiple aspects. This would potentially let u= s hang additional fields off of the access token request alongside the resou= rce list, but it would also mean that we=E2=80=99d have a degenerate case where yo= u=E2=80=99re defining an object with one member, whose value is always an array. I= n other words, this is exactly what the JSON Web Key Set format does, which = I=E2=80=99ve always found clunky. The top level object doesn=E2=80=99t add anything in t= he JWKS case, and I=E2=80=99m not seeing how it would add anything here. On the ot= her hand, this would let us use an object for a single access token and pote= ntially an array for multiple access tokens, but at some cost to the complex= ity at the layers below that.

 

None of those ideas lead to= a better syntax across the different uses cases, or that optimize for simpl= icity in the common use cases.

<= o:p> 

All that is to say that I = currently think that what we have is the simplest and cleanest approach that= I=E2=80=99ve seen so far, and I would really love to see if there are any alterna= tives that offer this same kind of power and clarity when exercised the same= . I would love to see some fresh ideas on different ways to approach this.



* 2.1= .1, "locations": are these really URIs or just URLs? On the other = hand, if these are URIs, why do we need a separate "identifier"? T= here's too much semantic overlap between "type", "location&qu= ot; and "identifier" - specifying just "type" may be suf= ficient.

 

In my implementation, =E2=80=9Clocations=E2=80=9D are actually just Strings tha= t the AS and RS can dereference to figure out the intended target of the RS.= In practice I think these will be URIs that identify the RS (or really, the= APIs hosted at each RS) in a way that the RC can communicate to the AS and = back. It=E2=80=99s not meant to be an exhaustive list of URLs that the RS will use= the token at, since an =E2=80=9CRS=E2=80=9D could have a nearly infinite set of URLs th= at it protects, depending on the nature of the API. GNAP shouldn=E2=80=99t take a = stance on the structure of the APIs it protects, much like OAuth didn=E2=80=99t.

 

<= p class=3DMsoNormal>=E2=80=9Cidentifier" is for an object identifier of some ty= pe within the API =E2=80=94 so while =E2=80=9Clocation=E2=80=9D is more to identify the RS its= elf, =E2=80=9Cidentifier=E2=80=9D is to indicate the item at the RS which might not be e= xposed through any kind of URL. 

 

=E2=80=9Ctype=E2=80=9D tells yo= u what=E2=80=99s in the rest of the object. The semantics are shared with OAuth RA= R, as mentioned in the note: https://tools.ietf.org/id/draft-ietf-oauth-rar-03.htm= l Though, as mentioned in the note, we can=E2=80=99t cleanly normatively = reference RAR directly as RAR needs to exist in an OAuth 2 world, which has = =E2=80=9Cscope=E2=80=9D and =E2=80=9Cresource=E2=80=9D parameters, as well as some extensions/profil= es that use an =E2=80=9Caud=E2=80=9D parameter and other items. We don=E2=80=99t have those re= strictions in GNAP and so the semantics are slightly different here. In an i= deal world, we=E2=80=99d define these in GNAP and RAR would be a clean back-port o= f this function to OAuth 2.

 

For a concrete strawman examp= le using OpenID Connect=E2=80=99s userinfo endpoint with the subject ID 2482897610= 01, we might have something like this:

 

{

 <= /p>

 

https://github.com/ietf-= wg-gnap/core-protocol/issues/11

&n= bsp;



* 2.1.1: i= t's implied but should be spelled out that the semantics of this example is = the cross product of permissions: I am requesting to read and write and &quo= t;dolphin" both "metadata" and "images", and that a= pplies to both "locations" - 12 different possible actions.

=

 

OK, th= at can be expounded upon here, as that is the intent. Each object is meant t= o encompass one fully realized combination of options, which is why they=E2=80=99r= e presented in an array overall (as talked about above).

 

https://github.com/ietf-wg= -gnap/core-protocol/issues/12

&nbs= p;

* 2.1.2: I don't see the value of the notion of "= expansion". It is sufficient that the string is understood by the AS.

=

 

W= hile I personally agree with your stance, this was from a discussion on the = list about the nature of the string value that we wanted to capture here.&nb= sp;



= * 2.1.2, "in some situations the value is intended to be seen and under= stood be the RC developer" - shouldn't we require this value to be alwa= ys fully documented by the AS owner, so that the RC knows what it is request= ing?

 

For cases when the developer sees it and configures it into the RC code= , I agree. But there are cases (like section 10.3) where things happen more = dynamically that are also enabled by this functionality. 



* 2.1.4: why are = flags represented as resources? The answer, "this is how OAuth 2 does i= t" is not great.

 

The idea is that these are items that alter what the a= ccess token that=E2=80=99s being requested in the =E2=80=9Cresources=E2=80=9D section. It is a= sensible way to hang things together since everything in the array ties to = a specific access token. This was a proposed design compromise, and if these= flags can fit elsewhere then we can do that.


https://github.com/ietf-wg-gnap/core-protocol/issues/13

 

* "the each access t= okens" -> each access token.

 

Thanks, got it!



* I suggest to extend the e= ditor's note to clarify what is the use case, so that the group can decide w= hether split tokens are indeed necessary.

&nbs= p;

I think we should have a more deta= iled conversation about this potential feature than an editor=E2=80=99s note could= reasonably get into. There are a number of large items (splitting access to= kens, directing access tokens to specific portions of API or RS=E2=80=99s, among o= thers) that I think will be big conversations for the WG, and all the contex= t of these don=E2=80=99t necessarily need to be documented inside the notes in the= document itself. 

&nb= sp;

But for discussion and context, t= his feature was proposed to deal with cases where the AS might decide to iss= ue several access tokens in any case where the client requested one, because= the AS wants to have restricted audiences for individual access tokens but = the client doesn=E2=80=99t know about the audiences ahead of time. I agree that it= =E2=80=99s a compelling use case, and it puts security of the protected domains in= the hands of the AS where it belongs, but it would require a client to be s= mart enough to know what to do with these tokens downstream, and if OAuth ha= s taught us anything it=E2=80=99s that we can=E2=80=99t rely on client software to be sm= art about most anything. :)



<= o:p>

https://github.com/ietf-wg-gnap/core-protocol/issues/= 14

 

* Why= is key binding of the access token even optional?

=  

Because people still want= to use bearer tokens as an option. I think we can make bound tokens first c= lass citizens in GNAP, and that=E2=80=99s a large reason behind having consistent = key binding approaches instead of having them separated out (section 8). I t= hink we can even make the =E2=80=9Cdefault=E2=80=9D having the token bound to the RC=E2=80=99s= presented key (and therefore make =E2=80=9Cunbound token=E2=80=9D a flag instead), but = I don=E2=80=99t think there would be support in the community for removing bearer = tokens entirely.


https://github.com/ietf-wg= -gnap/core-protocol/issues/15

&nbs= p;

* 2.2, "Subject identifiers requested by the RC s= erve only to identify the RO in the context of the AS and can't be used as c= ommunication channels by the RC" - this sounds a bit naive, people will= do that anyway. So why is this a useful statement? (And similarly in 3.4)

=

 

T= his inclusion is based roughly off of a similar constraint in OIDC around su= bject identifiers: https://openid.net/specs/openid-connect-core-1_0.= html#ClaimStability

&nb= sp;

I agree that people will do dumb = things anyway, but that=E2=80=99s why we ned to spell out why it=E2=80=99s dumb here.

 

https://g= ithub.com/ietf-wg-gnap/core-protocol/issues/16

 

* 2.3: what's the benefit of includin= g a URI (URL really) in "display"? Do we really want the user (RO)= to click links provided by the RC?

 

I think we want to give them the option = of doing so, yes. It=E2=80=99s up to the AS to help protect the RO, and that will = need to be written up in the security considerations. 

 

This is analogous to =E2=80=9Cclient_uri=E2=80=9D in OAuth Dynamic Registration: = ;https://tools.ietf.= org/html/rfc7591#section-2


https://gith= ub.com/ietf-wg-gnap/core-protocol/issues/17

 

* 2.3: why are we sending a JWK *as well= as* a cert? Are we checking that the cert contains the same public key as t= he cert?

 

I would be ok with the different formats being mutually exclusive s= omehow. The AS would need to check that they=E2=80=99re the same and throw an erro= r if not. But this would also let the RC send over whatever it=E2=80=99s got for i= ts own keys every time.


https://github.com/= ietf-wg-gnap/core-protocol/issues/18

 

=

* 2.3, " the AS MUST ensure that the key u= sed to sign the request... is associated with the instance identifier" = - can we be much more specific here, e.g. the instance_id MUST be byte-ident= ical to the Common Name of the cert? This "association" is never c= larified, either here or in Sec. 8.

 

No, I don=E2=80=99t think we should be so pres= criptive =E2=80=94 for one, it won=E2=80=99t always be a certificate or a JWK (where you= might use the Key ID). And for another, you might want to rotate the key wi= thout changing the instance identifier. And finally, I don=E2=80=99t think the CN = would even be enough since there will be plenty of cases where you=E2=80=99d be ac= cepting client-supplied keys. 

 

The =E2=80=9Cinstance_id=E2=80=9D= is an AS-assigned value that it can use to look up information about the in= stance of RC software making the call. Part of that includes whatever key in= formation is associated with that instance. The =E2=80=9Cassociation=E2=80=9D for this k= ind of thing is up to the AS, and in OAuth we called this =E2=80=9Cstatic client r= egistration=E2=80=9D or =E2=80=9Cdynamic client registration=E2=80=9D, depending on how it hap= pened. Here, we=E2=80=99re taking a step back from saying that =E2=80=9Ca client must be= registered=E2=80=9D and instead simply saying that =E2=80=9Cif you see an instance_id, = you need to know what key goes along with that and prove that that key is us= ed=E2=80=9D. For many clients, it=E2=80=99s the same net effect as having a client_id an= d registering their public key against that client_id in OAuth 2, but for la= rge swaths of clients that currently fall outside of the OAuth world, this i= s a more flexible overall model.

 

I=E2=80=99d like to understand= more about what you=E2=80=99re seeing here with regard to the keys, though, espec= ially since this section was restructured several times during the design te= am discussions and it could be more consistent and clear. 

 

YS: I=E2=80=99m actua= lly fine with this more loose definition.



* 2.3.2: allowing to send the key in m= ultiple formats virtually invites security vulnerabilities. Why is this a go= od thing?

 

See above, I think this is something we need to talk about more in= the group and I=E2=80=99m very open to having better ways present this informatio= n. I didn=E2=80=99t see a harm in having the same key in multiple formats, and JWK= itself already allows that with the =E2=80=9Cx5c=E2=80=9D field and related.=

 

https://github.com/ietf= -wg-gnap/core-protocol/issues/18 (again)

 

* 2.3.2: cert#256 is not a key, it's = an identifier. Why do we include it here? Note that in Sec. 8.3 you are usin= g the full certificate rather than the fingerprint.

 

It=E2=80=99s more than an iden= tifier, since an identifier could be an arbitrary value =E2=80=94 this is cryptogr= aphically derived from a specific certificate. If you=E2=80=99re doing MTLS, the c= lient is still sending the full certificate in the TLS layer, but this would= be a way to call out that certificate in a way that=E2=80=99s tied to the request= , without replicating it entirely within the request body. So it=E2=80=99s a way t= o send the certificate in a more compact fashion that you can verify, more t= han it is a way to identify a certificate whose value you=E2=80=99d need to go loo= k up.



* 2.3.2: why are we using raw PEM certificates instead of the JOSE represe= ntation?

 

The idea was to make it dead simple for developers. Not everything = runs on JOSE, but JWK is there if you want to use it (including JWK certific= ate representations). 



<= o:p>

=

* 2.3.3: For obvious security reasons, I suggest add= ing: The AS MAY choose to avoid displaying an arbitrary URI. RC developers m= ust only assume that the "name" field will be displayed.

 

I would a= ctually go farther in the security considerations and say that not even the = name is necessarily trusted for display. An RC could claim =E2=80=9CGoogle Docs=E2=80=9D= as its display name, and without other information being displayed (like ca= llback URIs or home pages), the RO=E2=80=99s got nothing to go on to figure out if= it=E2=80=99s really Google Docs or not. 


ht= tps://github.com/ietf-wg-gnap/core-protocol/issues/17

 

* 2.3.4, "created just fo= r this request" -> created just for this series of requests.

<= p class=3DMsoNormal> 

Got it,= thanks. 



* 2.3.4: I suggest referring to RCs that present unknown keys as = "anonymous RC", and then in 2.4, say that the AS MUST NOT accept a= ny assertions from an anonymous RC.

 

I disagree with this =E2=80=94 there are a lot= of cases out there where the RC isn=E2=80=99t =E2=80=9Canonymous=E2=80=9D at all but is still= presenting a key that the AS doesn=E2=80=99t know. And in fact, the RC might be p= resenting some assertions as to its own identity that the AS can verify.



* 2.4: = IMO assertion validation is a MUST, and we should specify what we require fo= r every assertion type we allow.

 <= /p>

I hear that point, but I=E2=80=99m just not sure = we can or even should get into that level of detail. 



* 2.4: moreover, when= possible, the AS MUST match the assertions to the presented sub_id. It may = be a hint, but you're not allowed to lie.

&nbs= p;

The reason that they=E2=80=99re a hint i= s that the client doesn=E2=80=99t really know who the user is yet. So I agree the = AS needs to process them, but that doesn=E2=80=99t mean it has to trust them. = ;



* = 2.4, "If the identified RQ does not match the RO present at the AS"= ; - I thought there are cases where the RQ is different from the RO. Also, I= am wondering why this is a SHOULD, not a MUST.

 

The SHOULD is exactly for th= at use case where they aren=E2=80=99t the same person. :) The idea is that the AS = would at least be able to detect that the user that the RC thinks is there i= s different from the one the AS sees. This might be fine for the AS for mult= i-person delegation use cases, and the AS can prompt the RO during authoriza= tion if that=E2=80=99s the case.

=  

I can see that this needs to b= e a lot clearer, and we can work on that text.



* 2.4.1 (but probably applicable = to any references): what is the lifetime of the reference? As an RC, how lon= g can I assume the user reference is still valid?

<= o:p> 

That=E2=80=99s up to the AS ulti= mately. Previous editions of the XYZ Protocol had lifetimes and other things= tied to the reference handles (defined in section 3.5), but it didn=E2=80=99t see= m like anyone actually cared about those parts in practice. A reference is e= ither going to work, or it won=E2=80=99t, and it could fail for reasons that have = nothing to do with a timeout that the RC can=E2=80=99t control or have input into.=


https://github.com/ietf-wg-gnap/core-proto= col/issues/19

 

* 2.5: "preferred_locales" is obviously not a mode of intera= ction. Why is it bundled here?

 

It controls an aspect of how interaction coul= d happen, which is what all of the fields in this section do. 

 

Even though it might look similar, these interaction modes aren=E2=80= =99t setting up things like the OAuth 2 =E2=80=9Cgrant type=E2=80=9D where the combination= s of parts are pre-defined and you=E2=80=99re signaling which combination you=E2=80=99re= after right at the start. Instead, the RC is saying what it can handle thro= ughout the interaction process. Some of these are things that get the user o= ver to the AS (redirect, user_code, app), some are for getting the user back= after interaction (callback), and some are about how interaction can be pre= sented before the RO is known (preferred_locales). All of these are aspects = of the interaction process, and it=E2=80=99s the combination of all of these toget= her that say what the client can do. In this model, each of these elements i= s independently defined, but they are all taken together as a single set of = parameters that can control the means of interaction with the user. So in on= e way of looking at it, you=E2=80=99re creating the =E2=80=9Cinteraction mode=E2=80=9D by defi= ning all of the aspects of that mode at once, including any potential parall= el alternatives (ie: redirect and app together). 

<= div>

 

Th= e discussion on bundles of interaction elements in the editor=E2=80=99s comment at= the end of 2.5.3 provides an alternative model that would allow the RC to d= efine multiple sets of these interactions, so that you could say, for instan= ce, =E2=80=9CI can get you to an arbitrary URL or type a user code but I can=E2=80=99t d= o a callback on those =E2=80=94 OR I could get you to an arbitrary URL and also do= a callback on that one=E2=80=9D. This kind of thing would let the AS decide to gi= ve out two different interaction URLs with different expectations on what to= do afterward, as opposed to right now where there is a single expectation o= f what to do afterward no matter which URL the user followed to get there.&n= bsp;

 

=

I=E2=80=99ll also note that we removed the term =E2=80=9Ccapabil= ity=E2=80=9D from this section as members of the design team found it confusing as= used here since it=E2=80=99s also used elsewhere in the document. I replaced it w= ith =E2=80=9Cmode=E2=80=9D, but that might have the wrong connotations. I=E2=80=99m happy for = suggestions of a better name than =E2=80=9Cmode=E2=80=9D, but I=E2=80=99m starting to wonder i= f everything should just be called =E2=80=9Ca thing=E2=80=9D everywhere. :)

* 2.5: the way "callback" = is described here is as a capability, not an interaction mode. The example o= nly strengthens this view, "callback" is a modifier of the "r= edirect" mode.

 

The =E2=80=9Ccallback=E2=80=9D field defines =E2=80=9Cwhat to do after int= eraction is done=E2=80=9D. Therefore, =E2=80=9Ccallback=E2=80=9D does not just modify =E2=80=9Credir= ect=E2=80=9D, it also potentially modifies other any other methods of getting the = user in front of the AS. When the AS figures out that it=E2=80=99s done with the R= O, it follows whatever steps the =E2=80=9Ccallback=E2=80=9D defines, regardless of how t= he user gets there. So for example, you could have the user present a user c= ode, and then follow a callback to push information back into the RC. Or you= could have some kind of in-app interaction and still have a callback.<= /o:p>

 

Inversely, you could have a redirect :without: a callback, lik= e if the user scans a QR code on a secondary device but doesn=E2=80=99t come back.=  



* 2.5: "use code" -> user code.

 

Got it, thanks.



* 2.5.1: this un= necessary polymorphism IMO just complicates implementations and prevents ext= ensibility. Instead, I would suggest:

redirect: {}

redirect:{max= _length: 255}

 

I find the pattern of sending an empty object problematic, and= we need to ask if there are other parameters that would really be sent here= . 



redirect:{max_length: 255, callback: {...}}

 

Again, the =E2=80=9Ccallback=E2=80=9D co= uld be applied to multiple outing options, but this would be an alternative = of including it as noted in the editor=E2=80=99s note in 2.5.3 about re-using the = =E2=80=9Ccallback=E2=80=9D field. 



<= o:p>

=

* 2.5.2: the "app" option is problematic, = as you already note. The RC may not even know if a given URL will result in = an application launching.

 

It depends on the nature of app =E2=80=94 it could be a = single URL like it is in many mobile platforms today but it could also be a = bundle of other information that can be used to launch the app. I don=E2=80=99t th= ink we=E2=80=99ll be doing any good by assuming things will continue to be single = URLs.



* 2.5.2: and shouldn't the RC include a list of supported applications? (W= hich would have lovely privacy implications.)=

=  

I think that=E2=80=99s a reasonable = dimension and one of the reasons =E2=80=9Capp=E2=80=9D launch should be separate from th= e =E2=80=9Cnormal=E2=80=9D redirect. I brought this up with some implementors in the fin= ancial sector a while ago, and with that group at least there wasn=E2=80=99t a lot= of desire for that kind of functionality. 

 

I agree = that there are some significant privacy implications driving this as well.&n= bsp;


https://github.com/ietf-wg-gnap/core-p= rotocol/issues/21

 

=

* 2.5.3: there's a parenthetical discussion on whether the URL is = unique. But the nonce parameter implies that the "hash" parameter = is unique per request, making this discussion moot.

 

I agree with you, if we = have a =E2=80=9Cnonce=E2=80=9D then you don=E2=80=99t necessarily need a unique URL, at least = not for security purposes. The editor=E2=80=99s note is to point out the inverse t= hat came up in design team discussions, that the =E2=80=9Cnonce=E2=80=9D is not needed t= o protect against some of the attacks if you require a unique URL. I would l= ike to see some formal analysis against this feature set as we build this ou= t. 



* 2.5.3: even if we need a different kind of post-interaction "red= irect", where the RC is not involved, there must be a way to ensure tha= t the RC receives positive (cryptographically protected) confirmation that t= he authorization was successful. In other words, what we're discussing here = is not an RC interaction mode, it is something else, and should probably hav= e a separate protocol element to describe it.=

=  

I=E2=80=99m on the fence about it be= ing something outside the interaction element, since it=E2=80=99s a kind of post-i= nteraction method just like =E2=80=9Ccallback=E2=80=9D already defines. I don=E2=80=99t think = it makes sense to allow a client to ask for more than one of these at a time= , and it could lead to some weird race conditions (do I poll if I might get = a callback?) and potential security issues (I polled but then got a callback= , is that an injection attack?). 



* 2.5.3: In the example for "interac= t" as an array (which I support), the second "redirect" and &= quot;user_code" should be independent elements of the array, not member= s of an object. This assumes they are truly independent interaction modes.

=

 

N= o, they are bundled together as the same element in the array on purpose. Th= is is the client saying =E2=80=9CI can send the user to a short URI or I can displ= ay a user code, but I can=E2=80=99t get a callback=E2=80=9D. This is equivalent to the O= Auth 2 device mode of displaying a QR code for the user to scan and giving t= hem a code to type into a static URL. The QR code is already an arbitrary UR= L and so it can use the same mechanism as =E2=80=9Credirect=E2=80=9D. To do what you=E2=80=99r= e asking you=E2=80=99d want a three element array. 



* 2.5.3.1: what does "RQ= is present on the request" mean?

 <= /o:p>

This is most clear for web server bas= ed RC=E2=80=99s: the session that was used to send the user outbound needs to be t= he same that is used when the return comes in. It makes less sense with othe= r interaction methods and other client types, but wherever possible the RC n= eeds to make sure that the user who started the request is =E2=80=9Cstill there=E2=80=9D= when the response comes back in the front channel. 

 

Is there a better way to say this without making it overly prescriptive?


https://github.com/ietf-wg-gnap/core-protocol= /issues/22

 

* 2.5.3.2: typo: HTTP the request.

 

Got it, thanks!



* 2.7: this seems to assum= e a short access token (which implies a bearer token). What if we want to us= e longer self-contained access tokens containing full keys? Should we have a= separate "grant_id" value instead?=

=  

I don=E2=80=99t see how this implies= a short access token, can you expand on what you mean by that? The access t= oken value will always be a string, opaque to the client, so if it=E2=80=99s self = contained and has its own keys wrapped inside of it in some way, that=E2=80=99s fi= ne and would still be enough for the AS to figure out what it means. 

 

<= p class=3DMsoNormal>There previously was the equivalent of a =E2=80=9Cgrant_id=E2=80=9D fo= r exactly this purpose =E2=80=94 it was the =E2=80=9Ctransaction handle=E2=80=9D in previous r= evisions, and it was also used for continuation and a number of other functi= ons. That feature has been phased out in favor of using either unique contin= uation URIs, access tokens, or a combination of both for managing the ongoin= g grant request process.  Having an explicit identifier would be helpfu= l for this specific use case, but it=E2=80=99s not needed for the more common use = cases anymore. Would it be worth bringing it back in?



* 2.8: another problem wit= h this stanza is that the RC needs to know a priority that the AS supports i= t. What happens if the AS doesn't?=

 

If the AS doesn=E2=80=99t support this, then it= gets ignored and has no effect on the resulting response. At least, that=E2=80=99= s how I think it should go =E2=80=94 we could also allow the AS to return an error= for fields it doesn=E2=80=99t understand, but that=E2=80=99s something that needs to be= consistent across the protocol in my opinion.



* 2.8: I suggest to move this sec= tion into a separate I-D, or at least a separate appendix.

 

As stated in the = last note in the section, I agree, and in fact don=E2=80=99t think we should be de= fining any use of OIDC within the GNAP working group. I think a good exercis= e would be to build out what an actual OIDC style protocol would be on top o= f GNAP, and it=E2=80=99s something I=E2=80=99d like to . The design team included this s= ection as a way to show how this type of externally-defined query language c= ould be incorporated, with all of its limitations and assumptions that come = with it. 



* 2.9: it makes sense to bundle extensions and the "capabili= ties" section into one.

 

<= /div>

While I see the point, the =E2=80=9Ccapabilities=E2=80=9D f= ield is really meant to signal specific extensions. It=E2=80=99s really loosely de= fined right now though, and I think that we need a lot more concrete applica= tions of the mechanism if we=E2=80=99re going to keep it.



* 2.9: The AS MUST ignore an= y unknown extension.

 

I=E2=80=99m OK with this stance, but it needs to be consisten= t throughout the protocol, not just at this level. 


https://github.com/ietf-wg-gnap/core-protocol/issues/23

 

* 3: it's conf= using that we're using access_token for two different things. Maybe we could= change the RC/AS one to "as_access_token"?

 

I disagree =E2=80=94 I think= we=E2=80=99re using them for the same kind of thing. They=E2=80=99re both access tokens= , and they=E2=80=99re used by the client in exactly the same way. The resource bei= ng accessed is part of the AS in one case, but the RS in the other case, but= you use the same kind of artifact in both cases to do the same kind of thin= g.  I think there=E2=80=99s a lot of power in re-using components like this i= nstead of inventing something special here.



* 3.1: MAY vary *by* request.

=

 

Got it= , thanks!



* 3.1: how is the client behavior "deterministic in all cases&quo= t; - how does the RC know whether the AS allows continuation or only allows = one request at a time?

<= /div>

 

<= div>

If the AS does not include a =E2=80=9Ccontinue=E2=80=9D field in = any of its replies, then the RC can=E2=80=99t continue it again. <= /p>



* 3.2.1: the &q= uot;value" of the access token is opaque in some cases (bearer token) b= ut not in others.

=

 

<= p class=3DMsoNormal>In what cases would it not be opaque to the client? In all= the current binding methods, this value would still be opaque and the RC st= ill has to send the token value.


=

=

* 3.2.1: The ASCII restriction on "value&q= uot; is insufficient. Needs to be printable ASCII, 0x20<v<=3D0x7f. And I= 'm not sure if this doesn't leave some characters that still need to be esca= ped.

 

That=E2=80=99s fair, and it=E2=80=99s currently a SHOULD anyway so I=E2=80=99m fine with = making it more restrictive in that case. OAuth 2 currently has the range &qu= ot;%x20-7E=E2=80=9D, but I=E2=80=99m not even sure how strictly that=E2=80=99s enforced in the= wild.


https://github.com/ietf-wg-gnap/core= -protocol/issues/24

 

* 3.2.1: why is "expires_in" optional? Typically acces= s tokens are not revoked, and the RC needs a way to manage their lifetime.

=

 

A= ccess tokens are revoked outside of the RC=E2=80=99s control in a lot of different= ways, not just timeouts. And there are non-expiring access tokens out there= as well. It=E2=80=99s possible, though in my experience exceedingly rare, for an = RC to preemptively get a new access token before expiry.



* 3.2.1: "resource= s" refers to this same section. Did you mean 2.1.2, or are we missing a= subsection describing resources/rights?=

 = ;

Good catch, this was in fact meant = to point to 2.1.1 (the anchors in markdown are similarly named since this is= the corresponding response to that request section).



* 3.2.1: "key": = another polymorphism alert!=

 

Yes, this is intentional use of polymorphism to = allow one field to represent different ways of related things instead of hav= ing multiple mutually-exclusive fields say the same thing. Right now it=E2=80=99s = got four possible values, and each of them answers the question =E2=80=9Cwhich key= is this token bound to=E2=80=9D:

 

Boolean =E2=80=9Ctrue=E2=80=9D: use the R= C=E2=80=99s presented key (ie, =E2=80=9Cthe key you sent=E2=80=9D =E2=80=94 the client doesn=E2=80=99t nee= d any additional identifying information to determine which key or method)

Boolean =E2=80=9Cfalse=E2=80=9D: bearer token= (ie, =E2=80=9Cno key=E2=80=9D)

Object: A sp= ecific key, not the one the client sent, either a public key for something t= he RC knows or possibly a full key pair (with private key) or a symmetric ke= y provided by the AS; I think we need more on this use case

String: A specific key, not the one the client s= ent, indicated by this reference that the RC can figure out

 

An RC looking at this field is always looking to answer the question of h= ow the token is bound, and this allows us to answer that definitively in a s= ingle space.

 

<= p class=3DMsoNormal>* 3.2.1: the example at the bottom of the section talks ab= out a way to present the token, I believe this discussion is out of context = here.

 

I=E2=80=99m not sure which example you are referring to here, since I don=E2=80=99= t see anything about a way to present a token. If you mean the editor=E2=80=99s no= te at the bottom about directed access tokens, this is relevant here because= the information needed to direct the RC where it should use the tokens woul= d be included in this response.


<= br>

<= div>

* 3.3: the AS knows now which interaction modes = are available. Why not pick just one for its response, to simplify the proto= col? As one example, the AS can then more easily decide on timeout behavior.=

 

The AS can do exactly that with the existing construction =E2=80=94 it can respon= d to only the parts that it wants to do for that specific request. 

 

For example, if the RC doesn=E2=80=99t include the =E2=80=9Ccallback=E2=80=9D = in its request but the AS decides, for security reasons, that it won=E2=80=99t ser= ve any requests without a way to return control directly to the RC post-inte= raction, then the AS can reject a request that doesn=E2=80=99t have that. 

 

For another example, if an AS decides that a specific resou= rce can only be authorized through a user code interaction (maybe it=E2=80=99s for= a resource/client format that the AS knows to be a limited device and so th= e AS has a specific usage pattern it will allow), then the AS can respond on= ly to the =E2=80=9Cuser_code=E2=80=9D portion of the client=E2=80=99s request, even if the cli= ent includes a =E2=80=9Ccallback=E2=80=9D and =E2=80=9Credirect=E2=80=9D parameter as well. 

 

Combining these interaction together is key to moving GNAP = beyond what OAuth 2=E2=80=99s extremely limited =E2=80=9Cgrant_type=E2=80=9D model allows.



* 3.3.3= : Suggest to add to the last paragraph: If the RC does not receive a callbac= k until an RC-determined timeout occurs, the RC MUST act as if the entire re= quest failed.

 

I=E2=80=99m fine with adding that kind of guidance. It gets fuzzy in= terms of security considerations though because =E2=80=9Can RC-determined timeout= =E2=80=9D without other guidance is so loose as to be undefined.



* 3.4: "updated_= at": Unix time is nice, but for absolute time it's common to use ISO 86= 01 format.

<= /blockquote>

 

I stole this field from OIDC, but I=E2=80=99m fine with any format here= , so if there=E2=80=99s no outcry we should change it in the next revision. <= o:p>



* 3.= 6: YES, the "error" element is exclusive!

 

I think it should be, bu= t I=E2=80=99d like to see if there=E2=80=99s any kind of counter argument. For example, = returning an error BUT also allowing continuation to address the error. Is t= hat allowed? If so we=E2=80=99d need to return the =E2=80=9Ccontinue=E2=80=9D field as well, w= hich is already defined. But if =E2=80=9Cerror=E2=80=9D means =E2=80=9Cthis is final, this req= uest is done now and forever=E2=80=9D, then yes it should be completely exclusive = of all others. 



* 3.6: in SecEvent we tried to use RFC 7807 "problem d= etails", I think it could work nicely here.

 

I=E2=80=99m unfamiliar with the d= etails of that spec, but after a quick skim I think that=E2=80=99s got some possib= ility. It seems to incorporate a lot of information from the HTTP message in= the response body though which isn=E2=80=99t really that applicable.



* 10.4: "in= dicating that GNAP" - sentence is broken.

 

Thanks, that meant to say &qu= ot;indicating that GNAP needs to be used to access the resource=E2=80=9D, fixed.



* Thi= s "speculative" access is not useful if the response is only a MAY= . Why would the RC try it if it is unlikely to provide useful information?

=

 

I= think the MAY is not quite the right normative application here. It=E2=80=99s a M= UST if you=E2=80=99re doing it to do it in this way, but it=E2=80=99s not a MUST for all= RS=E2=80=99s everywhere to respond in this fashion. If the RC tries calling an RS= that doesn=E2=80=99t respond with this, the RC simply doesn=E2=80=99t know, from any pr= ogrammatic or automated way, what to do to make the request actually work.


https://github.com/ietf-wg-gnap/core-protoco= l/issues/27

 

* 15: the BCP195 ref is broken - the author names are missing (yes I am = one of them...).

<= /div>

 

Yes, all the references need to be cleaned up! RFCs and IDs= get picked up automatically by the tools, but other documents (including, i= t seems, BCPs) don=E2=80=99t have that luxury. I focused on getting a basic refere= nce in place so that it would compile, and now I need to go back and make it= more correct. No offense intended to any of the BCP or other document autho= rs. :)



* Appendix D: can we name the first scenario, maybe "Simple API Acce= ss"?

 

I don=E2=80=99t think that is an accurate name for what=E2=80=99s being shown = here, and especially for what=E2=80=99s being highlighted. We are specifically sho= wing how to get API access through the use of fully redirect-based intera= ction =E2=80=94 redirect the user there, and have them redirected back. It=E2=80=99s= analogous to the OAuth 2 Authorization Code Grant Type. It=E2=80=99s very specifi= c to that aspect, and not really specific to =E2=80=9CAPI access=E2=80=9D. In fact, noth= ing in the scenario really needs API access for it to work =E2=80=94 the RC could = be asking for subject information instead and the rest of the example would = remain the same. This is the same scenario as discussed and diagrammed in 1.= 3.1, but with more extensive examples of protocol messages in use. 

 

 =E2=80=94 Justin


=

=

 

--B_3687104455_873818730-- From nobody Sun Nov 1 11:08: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 180DF3A0D29 for ; Sun, 1 Nov 2020 11:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, 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 MpFu8GO_jwkx for ; Sun, 1 Nov 2020 11:08:16 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 6EE3E3A0D05 for ; Sun, 1 Nov 2020 11:08:16 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id w14so12081263wrs.9 for ; Sun, 01 Nov 2020 11:08:16 -0800 (PST) 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; bh=1sCztdyH8ayzKZn//BGOLj+/yEnHTiDMu30I/nkI3uQ=; b=tUogXX3GN67QDtDZXOoQ5PejN1qo3o3SE+G3K3TcZgMnnCr086gAltK9bybK3qBBDP aOdHN9qrsNwEZuX7T55s/ChlRjoPe1rsR7i1c8DbNYh9qRlTE9LwiYZxawL+FVo1xHhX Hqo3qf9+L22aJiyXPdu2sjtVHmt0Dv4MvA+Df8tNOQmw/Q2LlbArrN0bjS7vtcEfMqHD nCo1VzmKxe2sdN8Gucvz4my8W0sptPyZHhvnVunMvWCRwtGbu+wBit2afKjjy2eAwCoe HJdoVukd18lR8QSnNRzUZBS8b+U019BJlCZhHWm0ZzZBJgelaIkyT6rbONBnQPyFTyWq hw/w== 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; bh=1sCztdyH8ayzKZn//BGOLj+/yEnHTiDMu30I/nkI3uQ=; b=pzO+1d1gHimtlx++5JqBWWK4LxXxvp8xdzAvv82aGvJDe280TE/JaU2I5CN3+PSlk1 ROWdLZbHrn/J7Y5FkQOnJqHoazXBtXYJ6Jn2NLQe8xr9nHIZ4A/KgHP/QwfnevX9GOyS XVigF4vkPZOkIgxCjCJOz2+WtGfw00+dUqaA8ekOQVC0igpZa53sOUkajuGx8d437W/u ZqqxdTe34FLRLSWSBCo7ecdgDhML2kDUbbPi9ZOpddTQX9rLWGUa8/+YpSxyqn4RNt3M uKfjCcFQtb4eKNUCskpIeh/PpdBei0vvxzqE01C6gBFjBLJxFiJXnasrw2DeEsKT9rDX ac4g== X-Gm-Message-State: AOAM532TLnT3bt/g4PqwefyGsWLgvU25W5sIIc1v6LFQ2CfLR4lZ06dr Trf28p4QhLBJ51rUMXR7/ktv2Zz2Skk= X-Google-Smtp-Source: ABdhPJxzkJbrwukG+Rl+7j+f8dFnspdoXcGGkU2pZkfiDLFultDybdflzxin2O1CXB8Ab/n7sKmyZA== X-Received: by 2002:adf:b190:: with SMTP id q16mr16447447wra.288.1604257694486; Sun, 01 Nov 2020 11:08:14 -0800 (PST) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id q6sm12676731wma.0.2020.11.01.11.08.13 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2020 11:08:13 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Sun, 01 Nov 2020 21:08:12 +0200 From: Yaron Sheffer To: GNAP Mailing List Message-ID: <51951B90-1932-41FC-885B-9A342DAEDF4B@gmail.com> Thread-Topic: Editorial team for the core protocol Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3687109693_1100042856" Archived-At: Subject: [GNAP] Editorial team for the core protocol X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 19:08:18 -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_3687109693_1100042856 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi GNAPpers, =20 Now that we have adopted the document [1], it is time to have more than one= person manage the work. The editorial team will together =E2=80=9Chold the pen=E2=80=9D= , and will ensure that the protocol follows the rough consensus of the worki= ng group. =20 Justin Richer authored the original document that became gnap-00. He will n= ow be joined by Aaron Parecki and Fabien Imbault as co-authors. =20 We would like to thank Justin, Aaron and Fabien, as well as several other p= eople who volunteered to join as co-authors but could not be accommodated. =20 Please give the draft a good read and share your feedback! =20 Thanks, =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 Leif and Yaron =20 [1] https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html --B_3687109693_1100042856 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi GNAPpers,

 

Now that we have adopted the document [1], it is= time to have more than one person manage the work. The editorial team will = together =E2=80=9Chold the pen=E2=80=9D, and will ensure that the protocol follows the r= ough consensus of the working group.

 

Justin Richer authored the original docume= nt that became gnap-00. He will now be joined by Aaron Parecki and Fabien Im= bault as co-authors.

 

We would like to thank Justin, Aaron and Fabien, as well a= s several other people who volunteered to join as co-authors but could not b= e accommodated.

 

Please give the draft a good read and share your feedback!=

&nbs= p;

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 Leif and Yaron

 

[1] https://www.ietf.org/archive/id= /draft-ietf-gnap-core-protocol-00.html

--B_3687109693_1100042856-- From nobody Mon Nov 2 07:56:31 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 5FFAF3A0EF9; Mon, 2 Nov 2020 07:56:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: txauth@ietf.org Message-ID: <160433257633.23038.15047041472414640530@ietfa.amsl.com> Date: Mon, 02 Nov 2020 07:56:16 -0800 Archived-At: Subject: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-01.txt 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, 02 Nov 2020 15:56:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Grant Negotiation and Authorization Protocol WG of the IETF. Title : Grant Negotiation and Authorization Protocol Authors : Justin Richer Aaron Parecki Fabien Imbault Filename : draft-ietf-gnap-core-protocol-01.txt Pages : 119 Date : 2020-11-02 Abstract: This document defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This delegation can include access to a set of APIs as well as information passed directly to the software. This document has been prepared by the GNAP working group design team of Kathleen Moriarty, Fabien Imbault, Dick Hardt, Mike Jones, and Justin Richer. This document is intended as a starting point for the working group and includes decision points for discussion and agreement. Many of the features in this proposed protocol can be accomplished in a number of ways. Where possible, the editor has included notes and discussion from the design team regarding the options as understood. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-gnap-core-protocol-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 2 08:11: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 BD04F3A0B28 for ; Mon, 2 Nov 2020 08:11:57 -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_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 LC07F3Ji_o5M for ; Mon, 2 Nov 2020 08:11:56 -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 E8CB03A0AF6 for ; Mon, 2 Nov 2020 08:11:55 -0800 (PST) Received: from [192.168.1.19] (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 0A2GBq1Z011313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 2 Nov 2020 11:11:53 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_2C530BA4-1576-4890-9EE0-CB3712B07A90" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 2 Nov 2020 11:11:52 -0500 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> To: GNAP Mailing List In-Reply-To: <160433257633.23038.15047041472414640530@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-01.txt 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, 02 Nov 2020 16:11:58 -0000 --Apple-Mail=_2C530BA4-1576-4890-9EE0-CB3712B07A90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This version adds Aaron and Fabien as authors (welcome, folks!), and = also incorporates some small editorial changes to fix typos, update = examples, and clean up the document itself. The one normative change is = the =E2=80=9Cupdated_at=E2=80=9D field for subject information is now an = ISO 8601 date string instead of an integer timestamp, which was = suggested as part of Yaron=E2=80=99s review and was a very simple change = to capture =E2=80=94 and didn=E2=80=99t have any detractors to the = suggested change on the list. If this change is a problem, please raise = an issue with the document. Other suggested changes have not been incorporated into the document = itself (either as comments or substantive changes) as the working group = is defining and adopting a new change management process for the = document to ensure transparency, clarity, and consensus. I=E2=80=99ll = let the chairs speak to the details on this as we all figure it out as a = group. Thank you, =E2=80=94 Justin > On Nov 2, 2020, at 10:56 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Grant Negotiation and Authorization = Protocol WG of the IETF. >=20 > Title : Grant Negotiation and Authorization Protocol > Authors : Justin Richer > Aaron Parecki > Fabien Imbault > Filename : draft-ietf-gnap-core-protocol-01.txt > Pages : 119 > Date : 2020-11-02 >=20 > Abstract: > This document defines a mechanism for delegating authorization to a > piece of software, and conveying that delegation to the software. > This delegation can include access to a set of APIs as well as > information passed directly to the software. >=20 > This document has been prepared by the GNAP working group design = team > of Kathleen Moriarty, Fabien Imbault, Dick Hardt, Mike Jones, and > Justin Richer. This document is intended as a starting point for = the > working group and includes decision points for discussion and > agreement. Many of the features in this proposed protocol can be > accomplished in a number of ways. Where possible, the editor has > included notes and discussion from the design team regarding the > options as understood. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-01.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-gnap-core-protocol-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_2C530BA4-1576-4890-9EE0-CB3712B07A90 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = version adds Aaron and Fabien as authors (welcome, folks!), and also = incorporates some small editorial changes to fix typos, update examples, = and clean up the document itself. The one normative change is the =E2=80=9C= updated_at=E2=80=9D field for subject information is = now an ISO 8601 date string instead of an integer timestamp, which was = suggested as part of Yaron=E2=80=99s review and was a very simple change = to capture =E2=80=94 and didn=E2=80=99t have any detractors to the = suggested change on the list. If this change is a problem, please raise = an issue with the document.

Other suggested changes have not been incorporated into the = document itself (either as comments or substantive changes) as the = working group is defining and adopting a new change management process = for the document to ensure transparency, clarity, and consensus. I=E2=80=99= ll let the chairs speak to the details on this as we all figure it out = as a group.

Thank you,
 =E2=80=94 Justin

On Nov 2, 2020, at 10:56 AM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Grant Negotiation and Authorization Protocol WG of the IETF.

=        Title =           : Grant = Negotiation and Authorization Protocol
=        Authors =         : Justin Richer
=             &n= bsp;           &nbs= p;Aaron Parecki
=             &n= bsp;           &nbs= p;Fabien Imbault
Filename =        : = draft-ietf-gnap-core-protocol-01.txt
Pages =           : 119
= Date =            : = 2020-11-02

Abstract:
=   This document defines a mechanism for delegating = authorization to a
  piece of software, and = conveying that delegation to the software.
=   This delegation can include access to a set of APIs as well = as
  information passed directly to the = software.

  This document has = been prepared by the GNAP working group design team
=   of Kathleen Moriarty, Fabien Imbault, Dick Hardt, Mike = Jones, and
  Justin Richer.  This document = is intended as a starting point for the
=   working group and includes decision points for discussion = and
  agreement.  Many of the features in = this proposed protocol can be
  accomplished in = a number of ways.  Where possible, the editor has
=   included notes and discussion from the design team regarding = the
  options as understood.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/=

There is also an HTML version = available at:
https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 1.html

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-gnap-core-protoc= ol-01


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

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

= --Apple-Mail=_2C530BA4-1576-4890-9EE0-CB3712B07A90-- From nobody Tue Nov 3 13:58: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 C43483A1220; Tue, 3 Nov 2020 13:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" 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 EXwuN9NWN6rw; Tue, 3 Nov 2020 13:58:03 -0800 (PST) Received: from DEU01-BE0-obe.outbound.protection.outlook.com (mail-be0deu01on2106.outbound.protection.outlook.com [40.107.127.106]) (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 7640B3A121C; Tue, 3 Nov 2020 13:58:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=anIE1JgsJ6szwVJUETg+KkuvVo857NYy74edEg5Qje8gxZZQIbhew/WytGzR0HA9OzVwFhvKGUIPljG0m8O2dSpFR7pzsF9eib3LPPc8dJsEGQXjfFRm+o466iUEjpCyp8MQdwwlr8Bx+WiyaATFzcO4XMzh6K2QWhCcrCcmhmNYa9rkX0YCZyz09SLtuB17nbQudzZ7xJAO4+euNwPSMMt54H8dJ44TIIj3XzKAaEOl54SeCktrP3VUme9wT4zEmCRecgqzpERoekdrHcaI1FO9yeAr3Iq8e5/zmRQ8j/Qghew9T4Fao3Ouw7re7KdzejZFQySCt3FNdX/+5zlzEw== 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=eR+tFTIcKmQ0I8CRqZlN9qrFttP0N3KGZs7nrxey4g8=; b=AQCGgG6+hZVOxwDcMfKInr59ZGRGSUXwBaFr1tOGFLrLt15WEN0yY3i0P7WT/+Yvwzwq9rIORly2+6aA2aNi7BtHg9PTi+SyuyCbyMjGD+bncp6lRB0a5fyW/1nd2aUb9/wzYcChC5bDX+OUq+yayDEC5H4lBWYYVQdHpg0eW0Qwvb/mU1tQZ3xr1kBnfJa4W3+bwrH1wRj9LQefqph0oChHpZC9AgxxG87URExQnumjqnWe4XqfIh4XvvE4iACDazJan3gMIPSBT36GBn4zQDW06E1HRBXTNWYYAgpG7b9aU2p7KHVgauCPSxUFPJvy0omQdTFE+MqmwCOpArODHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=adorsys.de; dmarc=pass action=none header.from=adorsys.de; dkim=pass header.d=adorsys.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eR+tFTIcKmQ0I8CRqZlN9qrFttP0N3KGZs7nrxey4g8=; b=Az6OUZP2kdNmfcs5cMjyLwLn0kbnn2hsrz12NjK5ef/2F9YRUYwSzsqdYqjvfdrVn0r+2EW0+iZ/lKGlZyRnu3NWuUv25WOXUIPYgkPw3/+o7iE6ptPX933W7vHhsmh02rnd18tXUdmo7RX9ja5AYLuknmGxCuXY5IniXagGvTK9ZV6N2yem/RBp66ZcN4ga0jOerPESxBgPXd8iVJHNDwlyFFIGrZzv4SUgNsv9d+vw3HRpovtqITBNjPs2rT4bQbWEJYzJx5EwAuRS/yrYWk0O1weELPK927+vJ3DJEDzIVkLiitoYKVWxAV7k7W7yv8E0cHz0ysAZa8Yr2N98Yw== Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:11::11) by FR2P281MB0268.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:10::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.15; Tue, 3 Nov 2020 21:57:59 +0000 Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::b06b:117e:61f0:138b]) by FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::b06b:117e:61f0:138b%3]) with mapi id 15.20.3541.013; Tue, 3 Nov 2020 21:57:59 +0000 From: Francis Pouatcha To: "i-d-announce@ietf.org" , "txauth@ietf.org" Thread-Topic: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-00.txt Thread-Index: AQHWpJRmsNLJEsCLXUKdo4jXxaYQ5am3CNs/ Date: Tue, 3 Nov 2020 21:57:59 +0000 Message-ID: References: <160294599277.27126.4949816992987431112@ietfa.amsl.com> In-Reply-To: <160294599277.27126.4949816992987431112@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=adorsys.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [65.33.157.159] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 12247c2a-d52e-4242-b4ec-08d880438759 x-ms-traffictypediagnostic: FR2P281MB0268: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RWosLLXJc+E3DV8eMA2iPZiTKqxIYJftCfI0n4CoDs1Gj0W9qjIC9F3P87heKXI/S5a3GVmg28yy29oGEUp3aDvZM0zdysSW9nnQuGuaXPcv+rs3EWST5Jc337WhnAcN5Bp9VJAetgecW1cTzMU33QV6LpbzNzzfaotedqcT8ps7cGBwseUTCbgQ4VMdYo8ZVGp+P92c/t6ntaWp5Mzng0k1IKobmfTFrF0Me7/FOEtIMHA7gtfPClYpx6/wUyEehQg85WGDbGcXItjI1kDOIoRIouCdAgqZF4RN3P4mqfwd2P1a8P7R/b3oVdvBC9gGM7FXjq72IIa5OxNEmxW9ABfU4GnC8sNdk9UGtup4MbR0i7e30f9Ms4aic2JRKc1Xi5yzFuQUVYxPLwoe/DPKFw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(136003)(396003)(39830400003)(346002)(450100002)(21615005)(19627405001)(8936002)(316002)(8676002)(110136005)(2906002)(86362001)(66476007)(66556008)(66446008)(64756008)(76116006)(91956017)(53546011)(7696005)(186003)(83380400001)(26005)(6506007)(55016002)(5660300002)(478600001)(9686003)(52536014)(33656002)(66574015)(4001150100001)(166002)(71200400001)(966005)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: y95elfqvBEP6KQqL+QKu1RRLKEmNIW7tmwXUDSVYDWjCcQ1VhteHLGf/r5bW3tfhYJsqNve2/Lcx9GpsfwdzkpEn1rdjmUU453dephbm45WN/MDc2LZRULENO516IkZ9fSQGm8GbfpJ/8E5WTjRHuaNoLvaq+7csMYGXfiqCs2yU8s2JdF0pn+N5CvFrQxrLSe6LAqQ5IC9r8hM6gSLEQVgOd4MwDv1Mdfnl1dEL298FffQso8T5LCdkLGvcx5GO1eN4AHrXzQT3rCxb0mMtPIcPJPzd5/YW5u7rsh8IcqEGjJ64oR/vzVEk1IbKNDxiRdL2kmzgkZxOp6yOk0MqOlFt1Qi499NFuWuG5XfweRA9Qvt+5wlj2/k+brwxgj6BbKPlqhzycV6R9qmpuWdPn/VVXaNbBv+oR3ASFbZMbXoVecKrdEsz8IpqgXaTecke9NMFIvT7RRkvmE7ek+HdN3X3Yet1qCv8zmI1St6cMQ9dWucPEkePRcjO4meV/GUkagQLsdzXPtPwU9IIP/tBWUHXkq5hTJtgeP38G+icxkJswHG2mvBXpcNjFOXbqpZ0LOcxfaz+l9liVzAbNeq89M7p8MRwtv8Pw9TxwHGvVZA+JEN+/1n7iZSTZb74skSKhHRMB1O4uixavhmMbRMtYQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FR2P281MB01063F61DE3A38E719310CC18D110FR2P281MB0106DEUP_" MIME-Version: 1.0 X-OriginatorOrg: adorsys.de X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 12247c2a-d52e-4242-b4ec-08d880438759 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2020 21:57:59.4215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5e2c5484-e522-479d-91ca-515d6e0ce228 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8DefeXWMJlaOkFdSvFL1yxuy7UuASjLzvnXyEyRSTOVP2JlLgzJ++BxnbrdQW6NfbvRPYferMAO143v+j19QjJXjrxsLyEYo8pc+gXbjEwo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0268 Archived-At: Subject: Re: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-00.txt 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, 03 Nov 2020 21:58:05 -0000 --_000_FR2P281MB01063F61DE3A38E719310CC18D110FR2P281MB0106DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sort of late but find below are my initial remarks after the first thorough= reading of the draft-ietf-gnap-core-protocol-00. A) Structure of the document Grant negotiation is of an importance that requires the draft document to h= ave a clean and understandable structure. This is missing. An example Struc= ture could be: 1- Introduction 2- Abstract Protocol Flow 3- Roles 3.1- Role 1 3.1.1 Definition 3.1.2 Scenario 3.1.3 Authentication 3.1.4 Capabilities 3.2- Role 2 4- Requests 4.1 Resource Request 4.2 Access Request 5- Elements 5.1 Element 1 6. Interactions 6.1- Interaction Type 1 6.1.1 Protocol Flow 6.1.2 Roles/Parties 6.1.3 Elements 6.1.4 Requests 6.2- Interaction Type 2 6.2.1 Protocol Flow 6.2.2 Roles/Parties .... 6.3- Interaction Type 3 B) Current Document Roles description shall not hold any assumption on the physical structure o= f the party fulfilling the roles. Roles: -> grant endpoint of the AS: Why is this a post request? This eliminates th= e chance of having user device hosted AS (no server). -> Resource Owner (RO) : Authorizes the request? Does it authorize the requ= est or the access to a resource? Missing Section Interactions: --> This section shall introduce the notion of interaction before we start = listing interaction types. Interaction Types: --> I prefer a classification with Redirect, Decoupled and Embedded is. In = the draft, we have one redirect and 2 decouple interactions and nothing els= e. Resource Access Request vs. Resource Request --> Both are mixed up. No clarification of the context of each section. Token Content Negotiation --> Not expressed as such. This is central to GNAP and not represented enou= gh in the document. Requesting "User" Information we identify two types of users: RQ and RO. It will be better not to refer t= o a user in this draft, but either to a RQ or an RO. Dealing with the RC. Here we need a clean structure: -> Identification --> Entity vs. Instance --> Display Information -> Key location, legitimation --> Authentication -> Capability representation Dealing with Users? This belongs to two sections: Handling RQ -> Identification --> Display Information -> Credentials --> Authentication Handling RO -> Identification --> Display Information -> Credentials --> Authentication Interaction Again -> For each interaction type, we will have to describe the protocol flow an= d the nature and behavior of involved Roles (Parties), Elements, Requests. Best regards /Francis ________________________________ From: TXAuth on behalf of internet-drafts@ietf.or= g Sent: Saturday, October 17, 2020 10:46 AM To: i-d-announce@ietf.org Cc: txauth@ietf.org Subject: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Grant Negotiation and Authorization Protoc= ol WG of the IETF. Title : Grant Negotiation and Authorization Protocol Author : Justin Richer Filename : draft-ietf-gnap-core-protocol-00.txt Pages : 119 Date : 2020-10-17 Abstract: This document defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This delegation can include access to a set of APIs as well as information passed directly to the software. This document has been prepared by the GNAP working group design team of Kathleen Moriarty, Fabien Imbault, Dick Hardt, Mike Jones, and Justin Richer. This document is intended as a starting point for the working group and includes decision points for discussion and agreement. Many of the features in this proposed protocol can be accomplished in a number of ways. Where possible, the editor has included notes and discussion from the design team regarding the options as understood. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --_000_FR2P281MB01063F61DE3A38E719310CC18D110FR2P281MB0106DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
sort of late but find below are my initial remarks after the first thorough= reading of the draft-ietf-gnap-core-protocol-00.


A) Structure of the document

Grant negotiation is of an importance that requires the draft document= to have a clean and understandable structure. This is missing. An example = Structure could be:

1- Introduction
2- Abstract Protocol Flow
3- Roles
    3.1- Role 1
        3.1.1 Definition
        3.1.2 Scenario
        3.1.3 Authentication
        3.1.4 Capabilities
    3.2- Role 2
4- Requests
   4.1 Resource Request
   4.2 Access Request
5- Elements
   5.1 Element 1
6. Interactions
   6.1- Interaction Type 1
        6.1.1 Protocol Flow
        6.1.2 Roles/Parties
        6.1.3 Elements
        6.1.4 Requests
   6.2- Interaction Type 2
   =     6.2.1 Protocol Flow
        6.2.2 Roles/Parties
        ....
   6.3- Interaction Type 3


B) Current Document

Roles description shall not hold any assumption on the physical struct= ure of the party fulfilling the roles.

Roles: 
-> grant endpoint of the AS: Why is this a post request? This elimi= nates the chance of having user device hosted AS (no server).
-> Resource Owner (RO) : Authorizes the request? Does it authorize = the request or the access to a resource?


Missing Section Interactions:
--> This section shall introduce the notion of interaction before w= e start listing interaction types.

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded= is. In the draft, we have one redirect and 2 decouple interactions and not= hing else.

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each sect= ion.

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represen= ted enough  in the document.

Requesting "User" Information
we identify two types of users: RQ and RO. It will be better not to re= fer to a user in this draft, but either to a RQ or an RO.


Dealing with the RC. Here we need a clean structure:
  -> Identification
     --> Entity vs. Instance
     --> Display Information
  -> Key location, legitimation
     --> Authentication
  -> Capability representation

Dealing with Users? This belongs to two sections:

Handling RQ
  -> Identification
     --> Display Information
  -> Credentials
     --> Authentication

Handling RO
  -> Identification
     --> Display Information
  -> Credentials
     --> Authentication


Interaction Again
-> For each interaction type, we will have to describe the protocol= flow and the nature and behavior of involved Roles (Parties), Elements, Re= quests.



Best regards
/Francis



From: TXAuth <txauth-bou= nces@ietf.org> on behalf of internet-drafts@ietf.org <internet-drafts= @ietf.org>
Sent: Saturday, October 17, 2020 10:46 AM
To: i-d-announce@ietf.org <i-d-announce@ietf.org>
Cc: txauth@ietf.org <txauth@ietf.org>
Subject: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-00.txt
 

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Grant Negotiation and Authorization Protoc= ol WG of the IETF.

        Title    &nb= sp;      : Grant Negotiation and Authorization Pro= tocol
        Author    &n= bsp;     : Justin Richer
        Filename    =     : draft-ietf-gnap-core-protocol-00.txt
        Pages    &nb= sp;      : 119
        Date    &nbs= p;       : 2020-10-17

Abstract:
   This document defines a mechanism for delegating authorization= to a
   piece of software, and conveying that delegation to the softwa= re.
   This delegation can include access to a set of APIs as well as=
   information passed directly to the software.

   This document has been prepared by the GNAP working group desi= gn team
   of Kathleen Moriarty, Fabien Imbault, Dick Hardt, Mike Jones, = and
   Justin Richer.  This document is intended as a starting p= oint for the
   working group and includes decision points for discussion and<= br>    agreement.  Many of the features in this proposed protoco= l can be
   accomplished in a number of ways.  Where possible, the ed= itor has
   included notes and discussion from the design team regarding t= he
   options as understood.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.htm= l


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet= -drafts/


--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/txauth
--_000_FR2P281MB01063F61DE3A38E719310CC18D110FR2P281MB0106DEUP_-- From nobody Tue Nov 3 14:00: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 122C33A122C for ; Tue, 3 Nov 2020 14:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" 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 vrFP22edMMXb for ; Tue, 3 Nov 2020 14:00:21 -0800 (PST) Received: from DEU01-BE0-obe.outbound.protection.outlook.com (mail-be0deu01on2111.outbound.protection.outlook.com [40.107.127.111]) (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 3864D3A1229 for ; Tue, 3 Nov 2020 14:00:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T3R3kxndr7oQ18VucUPOYjYbJkMuOYwWockKC5EI6cZIfp4Uq0/0aee7ZI0SRpJ9ZO27fKHUtr8frRjrPQGTwg1JMiN0zhm4WiBNZknKqeWUXRjjSPRXzMfKSeshZn/LqNZiZNu/8zlj0V5P124Mtp6ZblIGZGT3Yb3B37cH0R9JY84dzcqjkZzWY6dLfXm7NwENTzzM7Y0jUbYjSWmA2zo8DVbNBSNlt5qUY4D8b4j2cSaCyVEHGQk5I+san0RM84hIMUGiTRTL1ON1oT5/BhvIBpK7fy1O5EJKPzJNgKPOdtZ8bJMwgfqBGRtHXe61VDXTu0C/L06j/VZokoQ+dQ== 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=j5i4Pyhp/KMaXjsaxYKTTfYtU6bnObTjy1rx7TAxwbc=; b=duTrU0W4FKqcB1Rty9dhMKlC72TZZFyOKmv2F6W3NXyNaODm2TcLq+Ln1a/y0Ty7WKtMjd2v1xTWBdUKS4C3GIwDb9Hp43SH1x4HUmSDRPVZWVGDXAtIGgIhfJz+MX1xV9A1ZU5mzSkabNzksOS22VJh/qSCq8BTrBRvB9F4YuarLzfETzSU2cO30iIUbgNmbbHhNt7X8/Ue0A+CKWYnTtb8tLH/2t4z0hiF1EO0rdi5AJlJbdjhkU6GnHNPKBV0WWolY4nOdhqRHlFVYdUkcEegKgHoGJTYDY/u9WrHSqPgwQAUlh2ESNfoJIxiLvkdrCdtvDzE8G2VlH+Mcz7RRQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=adorsys.de; dmarc=pass action=none header.from=adorsys.de; dkim=pass header.d=adorsys.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j5i4Pyhp/KMaXjsaxYKTTfYtU6bnObTjy1rx7TAxwbc=; b=RCImY/r8NQX/aVWlQ6i94cRh7quD3sMPrnCwUO3nUIIsTmPaj4GqTrXcszq3XMjE0RSj4BKGb2zpSnF0ii7/Je0hr90IKfIDhkkpLMJzh38k9SQt7A/asR4xWu0+T4ZWPTl4zPSU7Z4IbSGU19yWUigI0AfD7zXk20ihu/G3RW/YtJ02EStfOQv6jM0CL4Qo+oXsnS+Sq4Tj4KoBi28Y53woJ8jhIUrmFaV/MWTqjMdsjamVTWOp5/VS2zFr6MVn8ga4a1WhjexS8Cp8QsXpxofVtUev72bKXx+1xye66O+lIxiLuQJPQv484RITUWx2OQgXGFqbTXiwagmuskRrgw== Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:11::11) by FR2P281MB0268.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:10::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.15; Tue, 3 Nov 2020 22:00:18 +0000 Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::b06b:117e:61f0:138b]) by FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::b06b:117e:61f0:138b%3]) with mapi id 15.20.3541.013; Tue, 3 Nov 2020 22:00:18 +0000 From: Francis Pouatcha To: GNAP Mailing List Thread-Topic: [GNAP] Review of draft-ietf-gnap-core-protocol-00 Thread-Index: AQHWsiy3H8is1hHc2keFJtXpCHRvoA== Date: Tue, 3 Nov 2020 22:00:18 +0000 Message-ID: References: <160433257633.23038.15047041472414640530@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=adorsys.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [65.33.157.159] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 163dfce2-f937-4297-69f3-08d88043da46 x-ms-traffictypediagnostic: FR2P281MB0268: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HUkTCSCkw7EVZtmu+2+VfjnSSuvQGOOkmyD3/Vm9KLY52J6oKLVTHoMQ7Zh7HmiUe8p2cL3RAWiAjpXTtcxFtOJ9QTHauKGhIBavYLNHOx/kpdZRiuoOPmPk4rPhpNl0Avg+FJUoCLzK6DIUt3UDEtv/c7I+WMKzlpNV77YOT0K3hTwpzGxQwdOOyf7LkOyPkQXIohZZ8TwpX3I2/5MOP/fzhMx3fctfQvGex2lpXutKhbRu+LcNbxNiO6muD8YgmKS+yDUbK7Xgpx8w+MPx8NQGsUQyvoTTG7vqJU0nfLAfl6QK2VWRzvO/93MX3wSnFUekQjaRQOA95jdjlsQioA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(136003)(396003)(39830400003)(346002)(6916009)(19627405001)(8936002)(316002)(8676002)(2906002)(86362001)(66476007)(66556008)(66446008)(64756008)(76116006)(91956017)(7696005)(186003)(83380400001)(26005)(6506007)(55016002)(5660300002)(478600001)(9686003)(52536014)(33656002)(71200400001)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: pM8J3V9TI5xgXeWJTV4czR3sJCkSgfQIrI5ae8+PhI1UetZW3N49EBvSJdspFpioWMZbOjInB/zLtVwcL1gWJS45fP8a2GHtyAfPWdpgwzsMbI8n8DxqrS4hJP0kksgMiy+K3+CVmg9+JAopcBvIGvITNGxpKLWU5EEtHT4Nnnx11hjVlrcdw5Rf+UpK7ujWHD97XeN7LG0BF1ku+OlkeHMqHz7HZ1vI8eQkLMnUxkRkBaWvXTisoz8zrQkK4aRyARdHaPXAlRtYxU9In99uqCNbgCMhP1w7cbAJyRYoQcvm08Xf2fLpIvIQqLJgNJjk0F6BqUX216uACnS5MjHEuhwKOqRT+sX4nc02H8jjAgo2UCLG4/aLS0ziDOKyB8TgXN7ZOyBpVy1g0GOvQT/kE7XI2ozANTGQGIznngzAoBw77uGShqudocdI/kDI0k/hTXtV6uAE6Ik8Qe0TC6ZIDB5/Mhv7dYXvCBjKaBCGkr500Db6XlXKAPSQVO2WyAbGbBYSXfkfcjrDfK0RXExgkG2xklVB7Y4wFSJofZrBl9Zh8qPoxGKtnnhIxv28D5FlNDSZfqkZMkE0nHdeosl5p/mo0TYPVGoWBesFSsqSeIBp/DtLLzfHBMfM6G/A0o7FaEIZCEY4HEregtHO3VRk6A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FR2P281MB01063C2EA739E892B549611D8D110FR2P281MB0106DEUP_" MIME-Version: 1.0 X-OriginatorOrg: adorsys.de X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 163dfce2-f937-4297-69f3-08d88043da46 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2020 22:00:18.5041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5e2c5484-e522-479d-91ca-515d6e0ce228 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: seUwlpSJxvZjghdW++rvwChqt0xVMAWGU/a9nHYjANeaM5h8h/bku7CbyOtCSPSuv6dZKzES6wPFR0L3jdJMA4xWYT6BsP++/q73QYqMUxE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0268 Archived-At: Subject: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 03 Nov 2020 22:00:23 -0000 --_000_FR2P281MB01063C2EA739E892B549611D8D110FR2P281MB0106DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sort of late but find below are my initial remarks after the first thorough= reading of the draft-ietf-gnap-core-protocol-00. A) Structure of the document Grant negotiation is of an importance that requires the draft document to h= ave a clean and understandable structure. This is missing. An example Struc= ture could be: 1- Introduction 2- Abstract Protocol Flow 3- Roles 3.1- Role 1 3.1.1 Definition 3.1.2 Scenario 3.1.3 Authentication 3.1.4 Capabilities 3.2- Role 2 4- Requests 4.1 Resource Request 4.2 Access Request 5- Elements 5.1 Element 1 6. Interactions 6.1- Interaction Type 1 6.1.1 Protocol Flow 6.1.2 Roles/Parties 6.1.3 Elements 6.1.4 Requests 6.2- Interaction Type 2 6.2.1 Protocol Flow 6.2.2 Roles/Parties .... 6.3- Interaction Type 3 B) Current Document Roles description shall not hold any assumption on the physical structure o= f the party fulfilling the roles. Roles: -> grant endpoint of the AS: Why is this a post request? This eliminates th= e chance of having user device hosted AS (no server). -> Resource Owner (RO) : Authorizes the request? Does it authorize the requ= est or the access to a resource? Missing Section Interactions: --> This section shall introduce the notion of interaction before we start = listing interaction types. Interaction Types: --> I prefer a classification with Redirect, Decoupled and Embedded is. In = the draft, we have one redirect and 2 decouple interactions and nothing els= e. Resource Access Request vs. Resource Request --> Both are mixed up. No clarification of the context of each section. Token Content Negotiation --> Not expressed as such. This is central to GNAP and not represented enou= gh in the document. Requesting "User" Information we identify two types of users: RQ and RO. It will be better not to refer t= o a user in this draft, but either to a RQ or an RO. Dealing with the RC. Here we need a clean structure: -> Identification --> Entity vs. Instance --> Display Information -> Key location, legitimation --> Authentication -> Capability representation Dealing with Users? This belongs to two sections: Handling RQ -> Identification --> Display Information -> Credentials --> Authentication Handling RO -> Identification --> Display Information -> Credentials --> Authentication Interaction Again -> For each interaction type, we will have to describe the protocol flow an= d the nature and behavior of involved Roles (Parties), Elements, Requests. Best regards /Francis --_000_FR2P281MB01063C2EA739E892B549611D8D110FR2P281MB0106DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
sort of late but find below are my initial remarks after the first thorough= reading of the draft-ietf-gnap-core-protocol-00.


A) Structure of the document

Grant negotiation is of an importance that requir= es the draft document to have a clean and understandable structure. This is= missing. An example Structure could be:

1- Introduction
2- Abstract Protocol Flow
3- Roles
    3.1- Role 1
        3.1.1 Definition
        3.1.2 Scenario
        3.1.3 Authentication<= /div>
        3.1.4 Capabilities
    3.2- Role 2
4- Requests
   4.1 Resource Request
   4.2 Access Request
5- Elements
   5.1 Element 1
6. Interactions
   6.1- Interaction Type 1
        6.1.1 Protocol Flow
        6.1.2 Roles/Parties
        6.1.3 Elements
        6.1.4 Requests
   6.2- Interaction Type 2
   =     6.2.1 Protocol Flow
        6.2.2 Roles/Parties
        ....
   6.3- Interaction Type 3


B) Current Document

Roles description shall not hold any assumption o= n the physical structure of the party fulfilling the roles.

Roles: 
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?


Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough  in the document.

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.


Dealing with the RC. Here we need a clean structu= re:
  -> Identification
     --> Entity vs. Instance
     --> Display Information
  -> Key location, legitimation
     --> Authentication
  -> Capability representation

Dealing with Users? This belongs to two sections:=

Handling RQ
  -> Identification
     --> Display Information
  -> Credentials
     --> Authentication

Handling RO
  -> Identification
     --> Display Information
  -> Credentials
     --> Authentication


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.



Best regards
/Francis

--_000_FR2P281MB01063C2EA739E892B549611D8D110FR2P281MB0106DEUP_-- From nobody Fri Nov 6 10:24: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 91F8C3A0AA0 for ; Fri, 6 Nov 2020 10:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSHucvmBTWpM for ; Fri, 6 Nov 2020 10:24:15 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 10E923A0AA1 for ; Fri, 6 Nov 2020 10:24:14 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id c17so2281972wrc.11 for ; Fri, 06 Nov 2020 10:24:14 -0800 (PST) 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; bh=sAEeWNA/X9EQK7ekk3Qf3TQ9pORM41PggOQkT4Vv2jo=; b=Z7ox8TRnHh9Lx7X3pwcPw4L/yjuM+TLQhfpW9GO4HX4KtWkkix+OlMJWmWFyH85RmE Zo9CBH9AWEluU8A2nY1lcomsK8G5TpGgbLVUYl1tZtdEZW10hn2mSuWqgxHJUW796iwu jqdOLFXugdd2GCEOn7vIwNU5zFLi/yQMIO+q0GvVMoWkCKdgFepjSfOCJcbQOrhSRMAf 431vu2nXm2BrHFKQEbQ6PelhqNK8RAQh7kdwmilGrTHyn65RxZYOMRZTR4jGsmwWNFfr EM6mqGVJ2tYFeLyaWPNUQDjjqpR6WR7wCtNSiJpQ/XDXGRGVORXRbgdMmAnheDZTPJ+1 HRoA== 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; bh=sAEeWNA/X9EQK7ekk3Qf3TQ9pORM41PggOQkT4Vv2jo=; b=C1YoJV7XZBgC2LymCMb81bLL/MNFrJ9wHIwuYwZtKz7/WL1BV7UALpybA0L2u4aWX+ u3mOwkipCOt70vsMBIFyGoCGVZf9uuP8pq+EkP73Jd4Fq29sm/9C7lq1R5Xl7NHORcun Pz6EkM1ij04rbA64nZbH0yaCIKFc3wNnK7OM9QoPQUFwZyY7d/Gb6IczQKYY7zOuDW1G JhDvTygcZJkZ66d5qJuePtyqWFkWGFwB+iAmRqvXd9HoYi00MFlT5mM5bdJCP56jl0KV D7ZM9KCC4b0hNkGPwH+PCJl01cyMWz+xtPDp9iZRG1szr+jxDL00PGtPFUvc7zKVe7A/ UOZA== X-Gm-Message-State: AOAM532J+b6J7KLTsGrTFZa/p6x67fZnAsryyfdPk220I7SBUP16Oh+A iNo/CzPlORQ0tOdlCQ6/xCQaUTSrVrs= X-Google-Smtp-Source: ABdhPJyoMv5iSnm6lprqugYVEcVW85HAXWSHetcp+xFuoGQwXYPeGDGigQz9NM3lg69YXvicCoyK2g== X-Received: by 2002:adf:e8d0:: with SMTP id k16mr4011611wrn.362.1604687053093; Fri, 06 Nov 2020 10:24:13 -0800 (PST) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id b63sm3770483wme.9.2020.11.06.10.24.12 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Nov 2020 10:24:12 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Fri, 06 Nov 2020 20:24:11 +0200 From: Yaron Sheffer To: GNAP Mailing List Message-ID: Thread-Topic: IETF-109 GNAP agenda Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3687539052_176438302" Archived-At: Subject: [GNAP] IETF-109 GNAP agenda 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, 06 Nov 2020 18:24:17 -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_3687539052_176438302 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi everyone, =20 Just uploaded the following draft agenda. Please let Leif and myself know i= f you=E2=80=99d like any changes. =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 =20 # GNAP at IETF-109 =20 **Chairs:** Leif Johansson and Yaron Sheffer =20 Tuesday, Nov. 17, 5:00-7:00 UTC =20 * 5:00-5:10 Opening and agenda bashing: chairs * 5:10-5:30 Proposed process and discussion: chairs * 5:30-6:50 Core protocol: progress update, discussion of selected issues: = editors * 6:50-7:00 Next steps: chairs --B_3687539052_176438302 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi everyone,

 

Just uploaded the following draft agenda. Please= let Leif and myself know if you=E2=80=99d like any changes.

=

 

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

 

 

# GNAP at IETF-109

 

= **Chairs:** Leif Johansson and Yaron Sheffer<= o:p>

=  

Tue= sday, Nov. 17, 5:00-7:00 UTC

 

* 5:00-5:10 Opening and agenda bashing: chairs

* 5:10-5= :30 Proposed process and discussion: chairs

* 5:30-6:50 Core protocol: progress u= pdate, discussion of selected issues: editors

* 6:50-7:00 Next steps: chairs=

--B_3687539052_176438302-- From nobody Fri Nov 6 14:18: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 C6B643A0DCB for ; Fri, 6 Nov 2020 14:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 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_08=1.651, 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 4zKopK-0jnc8 for ; Fri, 6 Nov 2020 14:18:37 -0800 (PST) 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 0625B3A0DC9 for ; Fri, 6 Nov 2020 14:18:37 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id y25so2125847lja.9 for ; Fri, 06 Nov 2020 14:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=88K/i2HCkUaO/U7wJjhUWNVHYYS2waJKWPFLLaaVWVs=; b=nofpX+oh9mex+s2C2eIh8ONFbjfw0dDcpzmafjkpWMDZMkmDdxVjtPBLktXdTRpCVu xb+zBq8b11pu+b2xyhLMzixLCdJ/qGgyvFFhwt2zeVK8Vm7Hc9YZvFtBi8OGyP3/PzAH 2JpZPn4nZ8MvPrtDSvlmY7vCEP/GQcQopJVfcWjRq6flPuHKe5ScuJC07gQ5DOyT5bYb L6MZjJsDAoR8IO6LfsJIgICHqJ/acUcXeM+zcVdyjBubpA0PqX+kNlTPByrvrYfvNX19 LXYtg3ONdGqEZaMg3f28rDpIyOka2kUwWGAHvmt8lAt489LRvIEN7gNaHPYuiVFSpXEC 2f9w== 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=88K/i2HCkUaO/U7wJjhUWNVHYYS2waJKWPFLLaaVWVs=; b=DEQcCHzFCNblk3mYtS+hII/E2UfglbeQBQq5aDIqeFX7DirdgaZNFva0aLK/IrvyJR 1l/VHebYjVAXSnBLQdZc3hfU9uza6rHx3ugILZ39MlkYk5cLXJlFKS0I8i79fsBEbcpJ pwexzvkbyiakQeJC2GDBGXD/Xw7voluP+Uhcaoaxyj2NTvPUXnbmsmJESuddlbBpC1Xy zD3XqUGUYX4otmLk4FoPTJu/kKmhNlj2P7ND5ftEnhvVsc+EYKnfbWKTze1GQsZTqCub bnUjtPQo2ooXfq0YOqgfqdbuFnsMSj6QhBtwSVkm50oVSobIs1g+zzFsfsP+Zesa0ZA6 PmPg== X-Gm-Message-State: AOAM532sGw7oglAygHXLDJNaH07O3KWLkcy/6A247kO25+/cpRC3NjOv oBo+TrYwj0UM8cuJEwQ4MaIQdNs5jkAfJgLk+XE= X-Google-Smtp-Source: ABdhPJzi7vjcYGqyeIBd0M6nSxKJtBD/lL2BrY4zJS5TwGhk07IqQ5y955027LNxbW6ZttTtKb33w1GRNGuTmluyg+k= X-Received: by 2002:a2e:8056:: with SMTP id p22mr1395227ljg.437.1604701115098; Fri, 06 Nov 2020 14:18:35 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Fri, 6 Nov 2020 14:17:59 -0800 Message-ID: To: Leif Johansson , Yaron Sheffer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000efadfb05b37797f2" Archived-At: Subject: [GNAP] GNAP 109 Agenda & WG process? 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, 06 Nov 2020 22:18:39 -0000 --000000000000efadfb05b37797f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Leif / Yaron It is 10 days until our meeting. Checking in on the agenda, and when we will have discussion on the WG process such as the use of draft notes / email / GitHub issues. /Dick =E1=90=A7 --000000000000efadfb05b37797f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Leif / Yaron

It is 10 days until ou= r meeting. Checking in on the agenda, and when we will have discussion on t= he WG process such as the use of draft notes / email / GitHub issues.
=

/Dick
3D""=E1=90=A7
--000000000000efadfb05b37797f2-- From nobody Fri Nov 6 15:25: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 71B933A0E3D for ; Fri, 6 Nov 2020 15:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, 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 sHIblFHVycxk for ; Fri, 6 Nov 2020 15:25:22 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 E475F3A0E39 for ; Fri, 6 Nov 2020 15:25:21 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id b8so2958086wrn.0 for ; Fri, 06 Nov 2020 15:25:21 -0800 (PST) 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=pVfQfkQN66NS5wR9eHIhTaY8NyKTqBoa4SAMgLdCXTg=; b=qL2jq9AFcoDV03K3jj8yQI8/4xWbhpq/k9in28aYrmK0ZMzk8emnoT67f4Z+oqcSx2 gfepmjsP/2+VZ/qALBk1Ew+2s6MNGFXq3GcNWuzBktqTFci4xGh8xRQEeuTTT0TQQeUd TJpHjMkcVlIqSDrznMwikQilPlYvYPrd77FKbM8e+3jAVrOiJ7l/DvzMt6lN1CwhJOEk xDvhNz0dS3nq2KFoHfyLJaZoYxA5O/cIAD70nMIoPBVPa3QEA4pjCZGldyaMjThxUZDr jyuQTQoJmNtV3dIwy2+E6/tTWyPWCbRUXO1h22TWqJRuA+gFgZhPsqeh8DoUjae3WzeK cgiA== 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=pVfQfkQN66NS5wR9eHIhTaY8NyKTqBoa4SAMgLdCXTg=; b=Ifyg7Rmx8vrPKK81090QyC02TrOl8V5o3s3L2WjK2NTArfM6AKvZOzGth1CKyE/Jk0 1Q3ACbfT8lnd0HsHpr3pZx8geFpieo7Au35ZN2LUSdz1kADZvpPaL2TjtMWW2I0tOC3n fRMI9Uhyq138usdCY+WvEFky6BibT2ecN9Zw49cJOaiNR/IwBspqjnc1HE3mWkX/I7ET CY9H9qqNlb8viGxMHVi9PaXYYPX7VJKq1ezwhE0P0brwIqT2VmuBosaoDtl2AL2u7q61 +khPREBllJqSI/GzslewHFLomUCBG8tjtANrW95p3/f3WXd9jmlytC2715vJW1cYpcz7 PJDA== X-Gm-Message-State: AOAM5339Bu/+wp4HLvG386B5m7HSwVLVd1ly1+JJkmXs3CLuMSn9LEJb g5vxuFRehvj2XLmaCeRSHrI= X-Google-Smtp-Source: ABdhPJx/wVXavn2y7fnuQ1R81N3x5MoqI/Xvgl7N90jGw7nQRH5G0Lzi367qRklPN/jjwlFr1djs0w== X-Received: by 2002:adf:9407:: with SMTP id 7mr5380824wrq.182.1604705120150; Fri, 06 Nov 2020 15:25:20 -0800 (PST) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id w186sm4094236wmb.26.2020.11.06.15.25.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Nov 2020 15:25:19 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Sat, 07 Nov 2020 01:25:18 +0200 From: Yaron Sheffer To: Dick Hardt , Leif Johansson , GNAP Mailing List Message-ID: <939750E9-A325-4A4F-B854-0072D248C657@gmail.com> Thread-Topic: GNAP 109 Agenda & WG process? References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3687557119_1997736251" Archived-At: Subject: Re: [GNAP] GNAP 109 Agenda & WG process? 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, 06 Nov 2020 23:25:23 -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_3687557119_1997736251 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Dick, =20 You must have missed my earlier note, which had a draft agenda including a = 20-min. block on process. =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: Dick Hardt Date: Saturday, November 7, 2020 at 00:18 To: Leif Johansson , Yaron Sheffer ,= GNAP Mailing List Subject: GNAP 109 Agenda & WG process? =20 Hey Leif / Yaron =20 It is 10 days until our meeting. Checking in on the agenda, and when we wil= l have discussion on the WG process such as the use of draft notes / email /= GitHub issues. =20 /Dick =E1=90=A7 --B_3687557119_1997736251 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Dick,

 

You must have missed my earlier note, which had a draft agen= da including a 20-min. block on process.

 

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: Dic= k Hardt <dick.hardt@gmail.com>
Date: Saturday, November 7, 2= 020 at 00:18
To: Leif Johansson <leifj@sunet.se>, Yaron Shef= fer <yaronf.ietf@gmail.com>, GNAP Mailing List <txauth@ietf.org>=
Subject: GNAP 109 Agenda & WG process?

<= /div>

 

Hey Leif / Yaron

 =

It is 10 days until our meeting. Checking = in on the agenda, and when we will have discussion on the WG process such as= the use of draft notes / email / GitHub issues.

 

/Dick

=E1=90=A7

--B_3687557119_1997736251-- From nobody Fri Nov 6 17:04: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 8EA533A0EE6 for ; Fri, 6 Nov 2020 17:04:51 -0800 (PST) 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 pngB3rsoMbZX for ; Fri, 6 Nov 2020 17:04:50 -0800 (PST) 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 B6A523A0EC5 for ; Fri, 6 Nov 2020 17:04:49 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id l10so3403844lji.4 for ; Fri, 06 Nov 2020 17:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rr+ZXvgr+qADYcmPFXbB1LqhpLw2rxfd45mKMUxlWXg=; b=JdjkLPTc0QAsO+JYFQqgIzeosj1U4l5lVZ1xVkH3yrtb9BOyTJwv7TrOMDjUrifZD6 bCnSy5BFZjZuC+djXX05OWpfGEcFBTQKq2ewblfhqthD1+1uYkvpZql4IFy/SGnyNe5+ ySYq7Rfa9pl/BtbDPOR6kpnhZJatRMwKkX7Gaa5gDL1v9HAjGd3reejiOyWNC+muFeC6 XTZeljIiV/PtT0npTMbpuOq6xOhduXERQ/8AjDXVb/bkFYBAcZtMS0JYWa8YKi5FAJkq 8mynuuGp75dgWDoxmXi3vrFq9+NhzSuZE189rVh6tBYDlTgT3OeDDt+sDtT7HUhC8CIB 1NsA== 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=rr+ZXvgr+qADYcmPFXbB1LqhpLw2rxfd45mKMUxlWXg=; b=RLFwCtsC9+Y9/zMnVDujcV14Z0hYGL0i1NCXSQzmpGmzdhzbrxhaBezh2fWAZ2Y+D4 JQ8fvo/yWDJst+ouBtC+XF5GQQVQd9jP8IgBaOQn/2FLYwnUQTGh51j1L7kosI6YQ2+g +TlbIq5taNSL2HjLS1bqay8/V3oKcGNIgWF/w+KVoSBsduVhrtJgu43e9rANexkKymx/ t5zO5hwK1+P9umH/6PQV6DKYRiahe5lj4ilfHAUSIsa0yetIADfMCh3urv0ucnQsGkIV iyGZIcqC3nzvk0G6YbsPpRW1gIlfQkR0d4jrhwWL6f4HA14F53Lm8ufAtyUcgdjrw/rw J1AA== X-Gm-Message-State: AOAM530sWUdsEELrLOywd22VoKoaS71KfseLs/6P3ROSJ1lVxWmD1+EN 1+cDYYYDCSCO0ZTOv1hlGb1zI2TQUydC0oAqGLk= X-Google-Smtp-Source: ABdhPJxJyEeDTL3sGQOX8PTTYTDoRCGEaB0SWUtlVmSgrorMQ+iD4cIFHVd2XjSoZjC/nrh+hO1MbBhFlwuUOXGQh8Y= X-Received: by 2002:a2e:984e:: with SMTP id e14mr1830072ljj.110.1604711087505; Fri, 06 Nov 2020 17:04:47 -0800 (PST) MIME-Version: 1.0 References: <939750E9-A325-4A4F-B854-0072D248C657@gmail.com> In-Reply-To: <939750E9-A325-4A4F-B854-0072D248C657@gmail.com> From: Dick Hardt Date: Fri, 6 Nov 2020 17:04:11 -0800 Message-ID: To: Yaron Sheffer Cc: Leif Johansson , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000005687d605b379eafb" Archived-At: Subject: Re: [GNAP] GNAP 109 Agenda & WG process? 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, 07 Nov 2020 01:04:54 -0000 --0000000000005687d605b379eafb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I did miss it -- it looks great! =E1=90=A7 On Fri, Nov 6, 2020 at 3:25 PM Yaron Sheffer wrote: > Hi Dick, > > > > You must have missed my earlier note, which had a draft agenda including = a > 20-min. block on process. > > > > Thanks, > > Yaron > > > > *From: *Dick Hardt > *Date: *Saturday, November 7, 2020 at 00:18 > *To: *Leif Johansson , Yaron Sheffer < > yaronf.ietf@gmail.com>, GNAP Mailing List > *Subject: *GNAP 109 Agenda & WG process? > > > > Hey Leif / Yaron > > > > It is 10 days until our meeting. Checking in on the agenda, and when we > will have discussion on the WG process such as the use of draft notes / > email / GitHub issues. > > > > /Dick > > =E1=90=A7 > --0000000000005687d605b379eafb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I did miss it -- it looks great!
3D""=E1=90= =A7

On Fri, Nov 6, 2020 at 3:25 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Dick,

=C2=A0

You must have missed my= earlier note, which had a draft agenda including a 20-min. block on proces= s.

=C2=A0

Thanks,

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

=C2=A0

<= div style=3D"border-right:none;border-bottom:none;border-left:none;border-t= op:1pt solid rgb(181,196,223);padding:3pt 0in 0in">

<= b>From: Dick Hardt <dick.hardt@gmail.com>
Date: = Saturday, November 7, 2020 at 00:18
To: Leif Johansson <leifj@sunet.se>, Yaron= Sheffer <yar= onf.ietf@gmail.com>, GNAP Mailing List <txauth@ietf.org>
Subject: GNAP= 109 Agenda & WG process?

=C2=A0

He= y Leif / Yaron

=C2=A0

It is 10 days until our meeting.= Checking in on the agenda, and when we will have discussion on the WG proc= ess such as the use of draft notes / email / GitHub issues.

=C2=A0

/Dick

=E1=90=A7

--0000000000005687d605b379eafb-- From nobody Sat Nov 7 23:51: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 A51343A10AD for ; Sat, 7 Nov 2020 23:51:01 -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, 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=mnot.net header.b=RMLQg/+y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ML2jEZol Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOq7rTOaj2YU for ; Sat, 7 Nov 2020 23:50:59 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D543A10AA for ; Sat, 7 Nov 2020 23:50:59 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E2389611 for ; Sun, 8 Nov 2020 02:32:59 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 08 Nov 2020 02:33:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=WWNSMXMWklFk6LpVtqVZhrwh8f5SW+AYk0/Om5mwmzY=; b=RMLQg/+y LpGOXYCWxrpiGch8bttrJXXKKx/D5EViHa+Hur/4uN0A++R9OvXDlGWa70INyuqf X/x3A5pCI5Qd7I7DwCyg+qD/xqWA4BR6cs+mPseeFwozp5YKp6ua4UeVxNuhRh4s Yhgcf/57Hok0kF3o7H19VbnRMR9Ui5FN6yWKxjfvNf/eqqDKXQ53fVRBhPlsMJXt ntHj9hjnP56QPftuyU9ur+9rAm6kIUWL9dIAC3y31bN9h7Nn7+DXVpfht3cBjCWL MXuHaPXFoWpFyaQbRlSAQ4oCvbfRPik/kQorrQPxbpYIHCyqvZsFGIH+nNdZUDUX 3DOgQryQgjK04g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=WWNSMXMWklFk6LpVtqVZhrwh8f5SW +AYk0/Om5mwmzY=; b=ML2jEZoluNv6OiWwChQawHfcOo3knMzQZM09zY0JlvXIB 3Vp/EsONtTlmZlJjnbcDuHwDf7CRmxrbZCDzCvwaK3mJMFX0bpKD+CxqcrViaxJA M5p/3WHnASFdcCBSKRsNotCJwS5lzqjIttW4CULqf5aevs7Zr7uD6/UCvTBolb/j roImb5l/p/+38sL4r283/G+pP0Uzy5jKo4Keic8nOQXwJsnU1vAP6LISuCO0DDEW xdVfAZjFeud6GLwqtI1PuecHOU0yAsmklBRgraHBfZ4f2H9C0z4EHrtJMLhOiHn4 XgUsJlwgLsuq2XOAsK3QPxe2zGqzZKTqOjcxBtpGA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudduvddguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudefkedrkedurd egjeenucevlhhushhtvghrufhiiigvpeeinecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az59-950.internal.cloudapp.net (unknown [52.138.81.47]) by mail.messagingengine.com (Postfix) with ESMTPA id 499123280059 for ; Sun, 8 Nov 2020 02:32:59 -0500 (EST) Content-Type: multipart/alternative; boundary="===============4667166842168510313==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20201108073259.499123280059@mailuser.nyi.internal> Date: Sun, 8 Nov 2020 02:32:59 -0500 (EST) 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 07:51:02 -0000 --===============4667166842168510313== 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 (+22/-2/=F0=9F=92=AC6) 22 issues created: - RS Response for Speculative Access (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/27=20 - "updated_at" Format (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/26=20 - Access Token Format (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/25=20 - Access Token Format (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/24=20 - Unknown Extensions (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/23=20 - Being "Present on the Request" (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/22=20 - The App Option (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/21=20 - Interaction "Modes" (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/20=20 - References and Their Lifecycle (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/19=20 - RC identifies by Key vs. Cert (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/18=20 - Security of AC-provided URI (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/17=20 - "Bad" use of Subject Identifiers (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/16=20 - Token Binding (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/15=20 - Split Tokens (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/14=20 - Syntax of Flags (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/13=20 - Cross-Product of Permissions (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/12=20 - Semantics of Location, Type, Identifier (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/11=20 - Single vs. Multiple Access Tokens (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/10=20 - Clarify User-Code Interaction (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/9=20 - Terminology: Key (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/8=20 - Mandatory to Implement Subset (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/7=20 - Polymorphism (by yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/6=20 4 issues received 6 new comments: - #26 "updated_at" Format (1 by jricher) https://github.com/ietf-wg-gnap/core-protocol/issues/26=20 - #20 Interaction "Modes" (1 by jricher) https://github.com/ietf-wg-gnap/core-protocol/issues/20=20 - #19 References and Their Lifecycle (1 by jricher) https://github.com/ietf-wg-gnap/core-protocol/issues/19=20 - #13 Syntax of Flags (3 by jricher, yaronf) https://github.com/ietf-wg-gnap/core-protocol/issues/13=20 2 issues closed: - "updated_at" Format https://github.com/ietf-wg-gnap/core-protocol/issue= s/26=20 - Access Token Format https://github.com/ietf-wg-gnap/core-protocol/issue= s/25=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Added authors. (by jricher) https://github.com/ietf-wg-gnap/core-protocol/pull/28=20 1 pull requests merged: - Added authors. https://github.com/ietf-wg-gnap/core-protocol/pull/28=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============4667166842168510313== 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 November 08, 2020

Events without label "editorial"

Issues

ietf-wg-gnap/core-protocol (+22/-2/=F0=9F=92=AC6)

22 issues created:

4 issues received 6 new comments:

2 issues closed:

Pull requests

ietf-wg-gnap/core-protocol (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============4667166842168510313==-- From nobody Thu Nov 12 11:54: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 A9FA63A02BD for ; Thu, 12 Nov 2020 11:54:12 -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, 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 yf9pKlgRgJVa for ; Thu, 12 Nov 2020 11:54:11 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 56B433A02C1 for ; Thu, 12 Nov 2020 11:54:11 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id r12so7353177iot.4 for ; Thu, 12 Nov 2020 11:54:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mrTm7kpnXeBlojkFC/Y/FM6/OPrHYBbK7e5JLUt3LWk=; b=qWrKst+HL+zecXFTqqGLSz0cr2FjUNuNWf69ifF+JqQc8fYKljn3moPVXocvT9Ajid Hop+O5wDW1aX8P63m2NG0uyjUIyGBirE21gu0JMNqKQqsW16lkFZQ6v5CHqzBNgLjGr8 l89WZI0Nt4lR04rtz0IIxXi6B7DJXHkqOslz1NucKQ+DBs38yKcAFGoBGWxnx4RufMTy XLs6wf+CJl2xtE/43vorFIS0eqH4Akxz8waC7L+isYF8+Y9z3p9fkPIaW1peMoKtRFkF UDd1AEVJy4H11+iIDj5A+dmk2ZNZjnznOktSuCfJrh+Ej2u+16WXe8RjE0eiFiaRGZmN qQMw== 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=mrTm7kpnXeBlojkFC/Y/FM6/OPrHYBbK7e5JLUt3LWk=; b=RjNmoghXnnGyp8zY1SL+8YdreD7MpXrIfDTKPJMJprJPuIJLyj1cMniMIqfAH8Hamu rJvzQjbISiyWfXMbxTZxArRFhpfBbGs+78Gf+8VgAXsRXlL0TPsLJHfGMglOg9MPoZv2 vn/ALxvL+9B8mTLQ1kndlWGbWejjWq3+4ZaZTCkcW1WTjCe2tHKT15TqxwmfM6rYlbFS kRX22HL4nZhYzGBBYUJUpDnTGkAeL2PBwChdqOXiA93IZwvP4RW/kB0NzH3MfTkvrjKA 7qDsNeLhceUu3xLevQyDS3BupfbsRHkH/43tt6mR2ZnVuOa+4GXsIcV2+sytE8/E3Bxl ykKA== X-Gm-Message-State: AOAM530jBq3bDiQfYTZrHZGN/jt8uH5p/dX7++Opn5EQupbSRgtwI3cR MnInJnA+CZJUCVDyAr/+Q472BlFowkbk4qrAWeO1bOPBiDRAeQ== X-Google-Smtp-Source: ABdhPJwpD1zBCuFXpby66n8TDgzuPHLtULZYGFzWp/yiJy+npoadFsDGD11MFUIJsS/eLknHFjqD4HWSIMQb1hE3uHM= X-Received: by 2002:a02:48:: with SMTP id 69mr1144599jaa.108.1605210850388; Thu, 12 Nov 2020 11:54:10 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Thu, 12 Nov 2020 20:53:59 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000086ed8005b3ee468d" Archived-At: Subject: [GNAP] Input on GNAP terminology 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, 12 Nov 2020 19:54:13 -0000 --00000000000086ed8005b3ee468d Content-Type: text/plain; charset="UTF-8" Hi everyone, I've created a new issue that deals with terminology. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 We'd like to get your feedback on this, either informally (on the mailing list) or better if you have a concrete proposal, please comment on the issue directly. The objective is to make a PR that regroups the suggested changes related to the terminology, and also to describe the rationale for our choices within the git (so that we can get back to it later on). Cheers Fabien --00000000000086ed8005b3ee468d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,=C2=A0

I've created a n= ew issue that deals with terminology.=C2=A0https://github.com/ietf-wg-gnap/gn= ap-core-protocol/issues/29

We'd like to ge= t your feedback on this, either informally (on the mailing list) or better = if you have a concrete proposal, please comment on the issue directly.
The objective is to make a PR that regroups the suggested changes rel= ated to the terminology, and also to describe the rationale for our choices= within the git (so that we can get back to it later on).

Cheers
Fabien

=C2=A0
--00000000000086ed8005b3ee468d-- From nobody Fri Nov 13 04:57: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 ADC493A0957 for ; Fri, 13 Nov 2020 04:57:49 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=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 R1OrH6d_GxG4 for ; Fri, 13 Nov 2020 04:57:48 -0800 (PST) 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 02BF93A0934 for ; Fri, 13 Nov 2020 04:57:48 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id i18so8182127ioa.3 for ; Fri, 13 Nov 2020 04:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l6Krminzw8lrdBCcW6HBob7p1q+cGDVEKIobPlrNzCA=; b=jk8wBXgmRYl/zdFOW+0co47f4UfUon5iev3Ss1TXRCtC3WrJoWib82+hLnrBgfTczQ 9D5IFXEv8u4e8no749a45TgPt+m6WfbYhq9UCw36dhVsk10kZnxbvkINGq3xYzilWE2E 1YWYkhOrp7x8GPhZ47zq92+XBtBObJR9pXp9O/6HHyJLit5UXy7HfoDXENDLSw/iTf5E TOtxWS+jqsJw+/GbOdYw6HymznuxvHJ4TqV66yRIrcnplo6n8mRV0ZIgDVemZGtpLAFD E1X+4dS7EmQXtwkExr34m9QX6zFDcw5bDVMPIFT8JkxMPRZj0XFjmJ4FtjLsNtvfMy91 Krjw== 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=l6Krminzw8lrdBCcW6HBob7p1q+cGDVEKIobPlrNzCA=; b=KT7afSE+U+h27ubMJouFQLe0v1LL1ez5fbhsnjIN5fDVaIVdKEhLGxZweUEDvOW1Je jBP3+ZaiHCA6PZPXUZCeSZvKNz3ZZT41/kH+8wGRYcF1Vx3QxHZewyCghxnZdKAuSRqb Fs1+E7MDmcha882n8u5gisOzAaAIMR0Y5BmU+V1qauG17aXnD3qwYzBEIXLIDvLpakiA 7UZ3f2ALZIL0lBGKTBSWIqotyIpC2rKPzNL1OiRwCQqTbLKyHvn2Q9dsnC4+C6b4IVAu KjaYCxkqgpcnsJIcTL3MoZBGyWe2t2EIUlQGnw/ra/0RPTQxKfGxnG8teKIDxHJY5cx1 ToCg== X-Gm-Message-State: AOAM531wc53tq+vQr/X7bt/X4e23KcmMJkW2zLlghNQxvDaYzEQhou/H EghYnMxqzcswgSYwjfeP0yKTtQQihIXqppO3PvD4wZr6hbIA7YRv X-Google-Smtp-Source: ABdhPJxm5qZSpTgaJXTzg3v+BW/iABpJT5SkGu9Sj2whGlPxbEw4feCf3LrLdbgMD/Fbh1Gr4GzU/HM00ovbmW8adLU= X-Received: by 2002:a6b:6001:: with SMTP id r1mr1624161iog.144.1605272267178; Fri, 13 Nov 2020 04:57:47 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> In-Reply-To: From: Fabien Imbault Date: Fri, 13 Nov 2020 13:57:35 +0100 Message-ID: To: Francis Pouatcha Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000040c49e05b3fc934e" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 13 Nov 2020 12:57:50 -0000 --00000000000040c49e05b3fc934e Content-Type: text/plain; charset="UTF-8" Hi Francis, Thanks a lot for your feedback, never to late :-) - including I hope for my late answer. Reviewing the structure of the document might be useful indeed. I've opened a new issue https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30 As for the rest of your comments B: embedded as a comment with [FI] (i removed the parts related to the structure of the spec). Cheers Fabien On Tue, Nov 3, 2020 at 11:00 PM Francis Pouatcha wrote: > > B) Current Document > > Roles description shall not hold any assumption on the physical structure > of the party fulfilling the roles. > [FI] not sure what you mean > > Roles: > -> grant endpoint of the AS: Why is this a post request? This eliminates > the chance of having user device hosted AS (no server). > [FI] what would you propose instead? Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case. > -> Resource Owner (RO) : Authorizes the request? Does it authorize the > request or the access to a resource? > [FI] yes, we should make the wording clearer > > Missing Section Interactions: > --> This section shall introduce the notion of interaction before we start > listing interaction types. > [FI] yes > > Interaction Types: > --> I prefer a classification with Redirect, Decoupled and Embedded is. In > the draft, we have one redirect and 2 decouple interactions and nothing > else. > [FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded? In practice there's at least these modes: - redirect and redirect back - redirect to different browser or device - user code - CIBA > Resource Access Request vs. Resource Request > --> Both are mixed up. No clarification of the context of each section. > [FI] could you clarify what you'd expect. Btw on this topic, there's a more general discussion on whether we should make a distinction or not. > > Token Content Negotiation > --> Not expressed as such. This is central to GNAP and not represented > enough in the document. > [FI] right. This should be a specific discussion item. > > Requesting "User" Information > we identify two types of users: RQ and RO. It will be better not to refer > to a user in this draft, but either to a RQ or an RO. > [FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user or end-user most of the time. Cf in definition, currently we have Requesting Party (RQ, aka "user") > Interaction Again > -> For each interaction type, we will have to describe the protocol flow > and the nature and behavior of involved Roles (Parties), Elements, Requests. > [FI] yes > > > Best regards > /Francis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000040c49e05b3fc934e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis,=C2=A0

Than= ks a lot for your feedback, never to late :-) - including I hope for my lat= e answer.

Reviewing the structure of the document = might be useful indeed. I've opened a new issue=C2=A0https://github.com/i= etf-wg-gnap/gnap-core-protocol/issues/30

As fo= r the rest of your comments B: embedded as a comment with [FI] (i removed t= he parts related to the structure of the spec).

Ch= eers
Fabien


On Tue, Nov 3, 2020 at 11:00 PM F= rancis Pouatcha <fpo=3D40= adorsys.de@dmarc.ietf.org> wrote:

B) Current Document

Roles description shall n= ot hold any assumption on the physical structure of the party fulfilling th= e roles.
[FI] not sure what= you mean
=C2=A0
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model w= hen there is no server. That's something that was discussed several tim= es but I'm still missing the underlying architecture and use case.
=C2=A0
=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we shou= ld make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
<= div>[FI] this should be handled as a specific discu= ssion item. As a reminder, how would you define embedded?
=
= In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code
- CIBA=


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what you'd expect.=C2=A0 B= tw on this topic, there's a more general discussion on whether we shoul= d make a distinction or not.=C2=A0
<= div style=3D"margin:0px">

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should = be a specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
= [FI] yes that would avoid potential misunderstandings. Although in the end,= people will translate RQ into user=C2=A0or end-user most of the time. Cf i= n definition, currently we have=C2=A0Requesting Party (RQ, aka "user")

Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0
=


Best regards
/Francis

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000040c49e05b3fc934e-- From nobody Fri Nov 13 05:22: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 12ECD3A098D for ; Fri, 13 Nov 2020 05:22:07 -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, RCVD_IN_DNSWL_BLOCKED=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 TTpW3dyL3kiH for ; Fri, 13 Nov 2020 05:22:06 -0800 (PST) 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 F09333A08B1 for ; Fri, 13 Nov 2020 05:22:05 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id n129so9738339iod.5 for ; Fri, 13 Nov 2020 05:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lEFm7rPtHkSLoJipmDMbIKxFihHkiRoHCVwA9uQaMHE=; b=Ls7gRK/kSSKy4Y/5TIWvyXWOzEBgsBmKVVBcyRxf9kKffoVXgtB+Ue7gh3IuaauSuu akQaozIRc2+/FS9Sn9ZrwVhKdkop5Cjj8FvzvwNAelY3xIU/FUMIkTD2/lJiBW6fDFrm wvnkn/tUhQ2fkpR9vJUkwXMel0PYZqSRJqR2ClNEqh3IWs/vBHlMui41QHlLia4Vq3ZQ ewuKsQcLDkPjVf2vD1xX3Oo60w5pezv+nRvAe/gXzSaY7hmjj5luCM+SkqLe3i/bBKIX sky2Tn3blIc9hdcqb+JptP7QGYlpCbim8CN160QfHiG6YXPtk3Ipnrsx/0eOyw/7Lln7 ULtg== 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=lEFm7rPtHkSLoJipmDMbIKxFihHkiRoHCVwA9uQaMHE=; b=fVhkYp2blQ83iqH5jUOj7++/6AQ8Qp5AaIWRh03ZfavqN0pJmMsdbqUDeY9ygAwcZK 5Tzd4J/VcSyDUZH7wRV/MiA4Z9xsnm0GjAdQ5OU05OFlX0Pw71SHfzI+VrlFdJAkuoom c67XzxIvsE6OWvYTj0A8E1hyALoTOLK4PAPH1Xc7+LjS688pKwaFwyTHUyhpJ4rsHhlt lNGRwyTFMO1LJ8tp9x4j8YL6c2ekn83nl4FKxt28RkV/L9I04K/9h+4nM6xISaquDKRL auUPRLb5Nf5BkRKJQmFcdqdSasH1T/rWWKTiGp0w0nocxzMhL9Hta6V1NBt8wXbwbEVd GtJA== X-Gm-Message-State: AOAM5302Fnyl22lApTgZfkPH9WVdlV0ofnewfZw7XlcCLROK+Pc3rLri f0YSw6aFh5NH63AoMfcfQmcr0i0RzjxpSB/NQHNuESkkD9vlRN7N X-Google-Smtp-Source: ABdhPJw48gg+abszHK+UCmztvREGSxut9cwQReXvYw7Zd2l8yzY/5OvmRhnV5ZHRr0M5+l/WDj81OC35qZAOGUOd8So= X-Received: by 2002:a05:6638:d46:: with SMTP id d6mr1904860jak.124.1605273724941; Fri, 13 Nov 2020 05:22:04 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Fri, 13 Nov 2020 14:21:54 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000024789d05b3fceaa5" Archived-At: Subject: [GNAP] Managing the issues on git 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, 13 Nov 2020 13:22:07 -0000 --00000000000024789d05b3fceaa5 Content-Type: text/plain; charset="UTF-8" Hi, To manage the issues on github, it would be nice to have a well-designed tag system. Do you know any that are related to specs? (a bit different than tagging coding issues). There could be : - normative/informative - per type of issue : enhancement, rewording, etc. - per type of work : terminology, usecase, etc. - per feature type : interact, request, response, etc. Let's try to keep that minimal but useful enough for triage. Any input welcome. Fabien --00000000000024789d05b3fceaa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

To manage the issues on githu= b, it would be nice to have a well-designed tag system. Do you know any tha= t are related to specs? (a bit different than tagging coding issues).
=

There could be :=C2=A0
- normative/informativ= e=C2=A0
- per type of issue : enhancement, rewording, etc.
- per type of work : terminology, usecase, etc.
- per fea= ture type : interact, request, response, etc.

Let&= #39;s try to keep that minimal but useful enough for triage.
Any = input welcome.

Fabien
--00000000000024789d05b3fceaa5-- From nobody Fri Nov 13 05:39: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 F0E3C3A0C02 for ; Fri, 13 Nov 2020 05:39:21 -0800 (PST) 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 WuPJWD61VXqH for ; Fri, 13 Nov 2020 05:39:20 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 489403A0BB3 for ; Fri, 13 Nov 2020 05:39:20 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id b6so9957832wrt.4 for ; Fri, 13 Nov 2020 05:39:20 -0800 (PST) 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=/VJyFN4a1Al8Rmum81JQaNRLkMHnA4T1uGPwmdAZz0I=; b=J5wv7hiD1YfYlh54ICFYm5tnFvsQb8v6Dv2HIj08Fz3KV1sZpOHGwr03GdkyGDhn4m IYGGmA0/VSkIbMQV6LQspqbO45wQdx8r/wxCL0SZOJ0bJQzcyZ03f0oBsSGPpRU3rOg3 ZQPH4TvUbEOL7fRMjrEsoAJTbzkYA+DTKonvKddt3lbIcJcGTVw3GNaFKM1ahvTbqMh3 9bkSJ0b5dY15hjqatL4XT0TsuEBMCJBwHThr1GA91OQT24+5+3I5giD8l3zw/2eWMSdY peApgXu8y7QdPkMsBQe8xBLrJfGDYm+1vBIRLhkO1Lyy2eTtXG0XJB0SKZ5g66HImx2T KqZQ== 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=/VJyFN4a1Al8Rmum81JQaNRLkMHnA4T1uGPwmdAZz0I=; b=YqhHGwQ1VvoqiAx4AZ+iBCYetJzD2dIzQ4Q7KyHzi691Yx+620kHdiVAiux/dLm43u UXJP6NeeK2WjOB7iQ47aYcLcn6ZqSdCF7Uk+UKIGcyt08PEWeUgd7MQYCtT/9/gvge3X kRtlGOn8pmc3YNQDv/87v1gbeo/XqUH2OYVYuiNoFS4FqeXItjtwCzxjtGLTTOe29aJN APNRyx5BWvlilROkbKPrJoBroLRz7EaNRo/a36rRcQuqJB1pcQiR4VCwhuZy9UIPkaGZ hMPIbd7NaoENez5c2RGxN+kE4iw1EF0XWdqPC9J8cMwM7ZTzXy1OFZ8np5R6F8riSYlb lU+w== X-Gm-Message-State: AOAM533JzqrX+k52eLsyRpg0jc+TqHlorUPbsgAaDZVsj99yn2LX43oY Ld/hK8a9YngiiFM/OwYXZzg= X-Google-Smtp-Source: ABdhPJx4jb+E1sPuCMuQVv1Iv/znke8vT+RNaYCIVFNw1Mrkt84XSMi/s+lm9gob7RTUzxnDOS2Xig== X-Received: by 2002:a5d:5291:: with SMTP id c17mr3457123wrv.311.1605274758635; Fri, 13 Nov 2020 05:39:18 -0800 (PST) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id w1sm10021108wmi.24.2020.11.13.05.39.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2020 05:39:17 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Fri, 13 Nov 2020 15:39:16 +0200 From: Yaron Sheffer To: Fabien Imbault , GNAP Mailing List Message-ID: <979D6A5F-25A3-45CF-94FE-7C106A2EFC8E@gmail.com> Thread-Topic: [GNAP] Managing the issues on git References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688126757_735211253" Archived-At: Subject: Re: [GNAP] Managing the issues on git 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, 13 Nov 2020 13:39:22 -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_3688126757_735211253 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable The IETF approach [1] is to start with two labels, Editorial and Design, an= d then extend it if needed. We have a slot for process discussion next week,= and can also discuss it there. =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 [1] https://tools.ietf.org/html/rfc8874#section-5.4.1 =20 From: TXAuth on behalf of Fabien Imbault Date: Friday, November 13, 2020 at 15:22 To: GNAP Mailing List Subject: [GNAP] Managing the issues on git =20 Hi,=20 =20 To manage the issues on github, it would be nice to have a well-designed ta= g system. Do you know any that are related to specs? (a bit different than t= agging coding issues). =20 There could be :=20 - normative/informative=20 - per type of issue : enhancement, rewording, etc. - per type of work : terminology, usecase, etc. - per feature type : interact, request, response, etc. =20 Let's try to keep that minimal but useful enough for triage. Any input welcome. =20 Fabien -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3688126757_735211253 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

The IETF appr= oach [1] is to start with two labels, Editorial and Design, and then extend = it if needed. We have a slot for process discussion next week, and can also = discuss it there.

 

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

 

[1] https://tools.ietf.org/html/rfc8874#section-5.4.1

 

From: TXAuth <txauth-bounces@ietf.org> on behalf of= Fabien Imbault <fabien.imbault@gmail.com>
Date: Friday, Nov= ember 13, 2020 at 15:22
To: GNAP Mailing List <txauth@ietf.org&= gt;
Subject: [GNAP] Managing the issues on git

 

Hi, 

 

=

To manage the issues on github, it would be ni= ce to have a well-designed tag system. Do you know any that are related to s= pecs? (a bit different than tagging coding issues).

 

There= could be : 

- normative/in= formative 

- per type of is= sue : enhancement, rewording, etc.

- per type of work : terminology, usecase, etc.

=

- per feature type : interact, request, response, etc.

 

Let's try to keep that minimal but useful enough for triage= .

Any input welcome.<= /p>

 

Fabien

-- TXAuth mailin= g list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--B_3688126757_735211253-- From nobody Fri Nov 13 06:12: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 74BFD3A0962 for ; Fri, 13 Nov 2020 06:12:32 -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 xBubOhcXdG9J for ; Fri, 13 Nov 2020 06:12:30 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 AD36A3A0B9C for ; Fri, 13 Nov 2020 06:12:30 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id t8so9855608iov.8 for ; Fri, 13 Nov 2020 06:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rjwifQwxpUvW8nFDzudJ3NhMlXjacGFj9Cc8ro8zmaY=; b=G8F5od8WsavNzo0OwxYlL55q7Cc1Vlw5O1IxSjVsjO8t9GQHtIDD07bdeuWVqz+kQk lXJ7jbF2u4pYb0YijcYG92VY1LMRpiHsDRRVq4IpJdVKpZ/Rzn8CU7bF642+obX6M6M1 peYO9rZYOkZ47IaFXa6Bnp/3H1kBfzPzcWDd2yzaxkHg8CV+umX5bW75JYOlW8mLcoWj ZZVYnsKJxkAFH7KI8pWftBYZ9qcJiIP6JyZsYM+dV0258MBMG1Ql9kSzLRrj8oF1f3uA 3V9uXMI6DAYqfIFM0AnABGPtx5mpAeIhlzqqeIZ52fhEbg3XZX8hVFKtbwQlYT/rF9gU Y6ng== 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=rjwifQwxpUvW8nFDzudJ3NhMlXjacGFj9Cc8ro8zmaY=; b=FEf+GrWJjqqOPXt2pSZIemL0Jvy1amD5otoOVvfEapFQapIOTh4bzT8dTDCnDinwoa UZrj98qKAEKAhY1/IeA3ru8Zb163TtohlysfT0s3PUNUpW+fqdoQDb5SYbXA2fpJNIX7 Hyu/doZ/QdgPRqDKKDJp2dgYW2QLuVF5W86nOn4WDRJJQE7DzIcEN3XiET0v8xrbkW8Y Ok9QD2Owg8wQCbhJ2hHcFpd2kyOxERr3liTM7xMCDGRxDRepFCEj/OyJf6j4615tP4f7 TsKutpoyDJMPWtJzcFWsVqPTvMOAYBZZ2Lc2HCRgp4+nZ4nvxuxTM+oGhC35ACAb4jr6 lBwA== X-Gm-Message-State: AOAM530gW74uzJfjiMk0rD9cnlh76Zl3iiJ7Yh/4WvHRKFRzYrq6Pz// PdKtMEKlQfn1lPlTm5GhUmaTLSsX3PNZUSIhcXc= X-Google-Smtp-Source: ABdhPJzuE4Dob38Zs/xMbi3BfbZ7kaSDmvoB6S7i2jeoX+nS7Munudfp8SbNI91MAOTV4AMTfnWK+/asEsSpc1NeCvU= X-Received: by 2002:a5e:c119:: with SMTP id v25mr1951320iol.162.1605276749879; Fri, 13 Nov 2020 06:12:29 -0800 (PST) MIME-Version: 1.0 References: <979D6A5F-25A3-45CF-94FE-7C106A2EFC8E@gmail.com> In-Reply-To: <979D6A5F-25A3-45CF-94FE-7C106A2EFC8E@gmail.com> From: Fabien Imbault Date: Fri, 13 Nov 2020 15:12:18 +0100 Message-ID: To: Yaron Sheffer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000715cb405b3fd9edd" Archived-At: Subject: Re: [GNAP] Managing the issues on git 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, 13 Nov 2020 14:12:33 -0000 --000000000000715cb405b3fd9edd Content-Type: text/plain; charset="UTF-8" Sounds good. On Fri, Nov 13, 2020 at 2:39 PM Yaron Sheffer wrote: > The IETF approach [1] is to start with two labels, Editorial and Design, > and then extend it if needed. We have a slot for process discussion next > week, and can also discuss it there. > > > > Thanks, > > Yaron > > > > [1] https://tools.ietf.org/html/rfc8874#section-5.4.1 > > > > *From: *TXAuth on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Date: *Friday, November 13, 2020 at 15:22 > *To: *GNAP Mailing List > *Subject: *[GNAP] Managing the issues on git > > > > Hi, > > > > To manage the issues on github, it would be nice to have a well-designed > tag system. Do you know any that are related to specs? (a bit different > than tagging coding issues). > > > > There could be : > > - normative/informative > > - per type of issue : enhancement, rewording, etc. > > - per type of work : terminology, usecase, etc. > > - per feature type : interact, request, response, etc. > > > > Let's try to keep that minimal but useful enough for triage. > > Any input welcome. > > > > Fabien > > -- TXAuth mailing list TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000715cb405b3fd9edd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds good.

On Fri, Nov 13, 2020 at 2:39 PM Yaron Sheffer= <yaronf.ietf@gmail.com>= wrote:

The IETF approach [1] i= s to start with two labels, Editorial and Design, and then extend it if nee= ded. We have a slot for process discussion next week, and can also discuss = it there.

=C2=A0

<= p class=3D"MsoNormal">Thanks,

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

=C2=A0=

[1] https://tools.ietf.org/html/rfc8874= #section-5.4.1

=C2=A0=

From: TXAuth <txauth-bounces@ietf.org> on beha= lf of Fabien Imbault <fabien.imbault@gmail.com>
Date: Friday, Novemb= er 13, 2020 at 15:22
To: GNAP Mailing List <txauth@ietf.org>
Subject: <= /b>[GNAP] Managing the issues on git

=C2=A0

Hi,=C2=A0

=C2=A0<= /u>

To manage the issues on github, it= would be nice to have a well-designed tag system. Do you know any that are= related to specs? (a bit different than tagging coding issues).<= /u>

=C2=A0

There could be :=C2=A0

=

- normative/informative=C2=A0

- per type of issue : enhancement, rewording, = etc.

- per type of work = : terminology, usecase, etc.

- per feature type : interact, request, response, etc.

=C2=A0

Let's try to keep that minimal but useful enough for= triage.

Any input welco= me.

=C2=A0=

Fabien

<= p class=3D"MsoNormal">-- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/lis= tinfo/txauth

--000000000000715cb405b3fd9edd-- From nobody Fri Nov 13 07:56: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 E69E43A0E24 for ; Fri, 13 Nov 2020 07:56:44 -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, MIME_QP_LONG_LINE=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 6RVxlX5_3L4Z for ; Fri, 13 Nov 2020 07:56:43 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 63C243A0E34 for ; Fri, 13 Nov 2020 07:56:43 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id 33so10426892wrl.7 for ; Fri, 13 Nov 2020 07:56:43 -0800 (PST) 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; bh=NffP6VUSv9q82djDjdJwKJWGF2J+Jn7je3Cu86DVPv8=; b=f02FNZRhkJ5VqQKcS0Ya5xL/+mEQKOFVnoda2UphOGMgsU93eu9F1va3XYOB188YjJ jy6HvHkYrpz7Ee3sWIXi1Qaokjm06nq9YgqX/5sBkHaKDjJ8ka+SkrxCxWRBi7kbRb0K 76JHF4cEWebDLAzyAxwux+Z1ll8SaKug27cIfEsFBCkyH/QQHfBXh+lLgifKcqsS7n/+ 6DYyGq9ipFEZt+Lp6xIORizZ2FUQ8F8a5VnwKknRXxcHqsRB7b8fMlnTHz+CEm03BSO9 +Pd8GTZYozCEYl7nw/5fVZq88U6Iodsv5InL2NIA5UDxhZxBd/vXx5j6nMFazgi3AQlU DrWg== 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; bh=NffP6VUSv9q82djDjdJwKJWGF2J+Jn7je3Cu86DVPv8=; b=XAyZS3V5/aHwOJKwgqsqJGRRyV/XuR6i6gqoWZhJEFQUgJc99h9ifYHmiPuo8E3HyA Aj4TiVJhQC9eIHDoKRAWrjXJmzXogdHnG+2+Q2jcZIl1dX2h0lxFNcsyM2Au9WWEHh6n luqLFS6akOFlNOX1QLHcoWNBZgLUMzewmf5tZDPDGl/FpbRj9Hk9GmTHK+RCet70EFYB DKxyCnYWJOelw4gvU6Loc6l5NXueEWNZx1InIuwemPxmuTR8yI6YrARtrGjrv2joD01y hEZ9S2n+5zhYMEYecz5sKu56FQh0w4yPyQSOA8Un2jLgHjcShdAHoWVdgYJ1TxBl1OUm dchw== X-Gm-Message-State: AOAM530khYLi0ud/EY8eYXTTuLhFKso1Xe2hgSsGb24uGa1Tk0mgTfvn 5nSBlUM//gz2Lp6D7EqpUnbm9HiGRIY= X-Google-Smtp-Source: ABdhPJy1rVN8VNoNu018YTVa7K8Iev7I1dgYwiaPjJe4f3FBi/fQotsiwVo9OyE2zafHW1DQtuP2wg== X-Received: by 2002:adf:80eb:: with SMTP id 98mr4423946wrl.101.1605282996347; Fri, 13 Nov 2020 07:56:36 -0800 (PST) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id c5sm1339177wrb.64.2020.11.13.07.56.35 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2020 07:56:35 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Fri, 13 Nov 2020 17:56:34 +0200 From: Yaron Sheffer To: GNAP Mailing List Message-ID: <664DC2D5-350A-4795-AC15-18EBA7CB4D25@gmail.com> Thread-Topic: Another process comment - section numbers in issues Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688134995_1396961181" Archived-At: Subject: [GNAP] Another process comment - section numbers in issues 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, 13 Nov 2020 15:56:45 -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_3688134995_1396961181 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi everyone, editors in particular, =20 I suggest not to use section numbers in issues, because they obviously chan= ge over time, moreover, if we use section numbers, we have a strong incentiv= e to keep them from one version to the next and it's way too early for that. =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 --B_3688134995_1396961181 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi everyone, editors in particular,

<= p class=3DMsoNormal> 

I suggest not to use sect= ion numbers in issues, because they obviously change over time, moreover, if= we use section numbers, we have a strong incentive to keep them from one ve= rsion to the next and it's way too early for that.

 

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

--B_3688134995_1396961181-- From nobody Fri Nov 13 08:52: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 0A7E53A0F09 for ; Fri, 13 Nov 2020 08:52:01 -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 IMjg5FGcwq6V for ; Fri, 13 Nov 2020 08:51:59 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 8E95E3A0F02 for ; Fri, 13 Nov 2020 08:51:59 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id i18so8945922ioa.3 for ; Fri, 13 Nov 2020 08:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HNKbISGIANtiHzaJkWMnwYOOrEm6WADWp7zPFrzfurc=; b=Pco1+C/TftXAxGUfQ5WN6Aq6MNDJOEKEj7C6QXH9F+XD2rs+ymmSHQVVJy7RgzmCQs 5lqNQ5zAJjv67qBuDTgmJO4kTjkJmPGNf1YsLs9qihtweCklqW1t3Z3ggJO7WU3fruKD TeVvABWbV2Ue0w83vad8IA8AjEftSgqnDXZ9FQIq5jlCkRcqP523HaRGoogBqJAZs4Qb enIr6+nRtnBBWeZkkHxpEpDjIfmDsrJD+G7RWdaUoSxLoTJNTyTczgiEwm1+G64crjUn 3RQee/4m835hfSHU/awkOu61WsyK9giRZuy/ceG33AFce6XJvT0OntepHa4VWiru93bv 60ug== 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=HNKbISGIANtiHzaJkWMnwYOOrEm6WADWp7zPFrzfurc=; b=rQcS8ADVpEJ09mzSHapqhPcTabO2pJr1mNQr3Ei1q2ou5lbUQSbTt7p6zWo4la0M2t hmW6W5GdQfBi+WgQnMlOku9QfL+OeHClWsQmG6PcJaHPLT64QmhQK4fadCY2gH4z8dib j4JKtdr0pToTkBRqE5GB6oPtankJt/3gGlsKSqN+y/AlWR/A/Qihk6w4sH8qYlbL5gxQ 0SVUtkpBSnKxKC51/j2xQ/4jv7XnaU+Ya2YiJmtjRMdowdjesIBaRvaWikRU0/H7/dmg yS21idk3IczRDF5S3SpXIAhb1cNaeK5TY9YXV4ziX9yYTVYCzPnVhQlNnlEPY9FzFqj+ cWsw== X-Gm-Message-State: AOAM533Iv7ZrSXnI5wmpMsuxiXyumw22Ik6aXA40OAnBa+F3Kk1XJQ5j EHy9HoMThHH6s1QjkKZuBhzeuPTUaQ7P/O4nqig= X-Google-Smtp-Source: ABdhPJwzTgorLyKzyuEuSt22FjyrDznB8roLxL2h30vo21pMssCwvMMgF9Fqb+qHANopKX+w2tAlTMl4mA5/KPN17ck= X-Received: by 2002:a02:76d7:: with SMTP id z206mr2592027jab.77.1605286313767; Fri, 13 Nov 2020 08:51:53 -0800 (PST) MIME-Version: 1.0 References: <664DC2D5-350A-4795-AC15-18EBA7CB4D25@gmail.com> In-Reply-To: <664DC2D5-350A-4795-AC15-18EBA7CB4D25@gmail.com> From: Fabien Imbault Date: Fri, 13 Nov 2020 17:51:42 +0100 Message-ID: To: Yaron Sheffer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000007eb93a05b3ffd88f" Archived-At: Subject: Re: [GNAP] Another process comment - section numbers in issues 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, 13 Nov 2020 16:52:01 -0000 --0000000000007eb93a05b3ffd88f Content-Type: text/plain; charset="UTF-8" Hi Yaron, That's right, but we need to find a way to identify where the issue is located. For editor's notes, Justin has worked in the other direction : issues are refered from the spec itself. But we might not want to change the spec each time we have an issue, so I don't know what's the best solution here. Cheers Fabien On Fri, Nov 13, 2020 at 4:56 PM Yaron Sheffer wrote: > Hi everyone, editors in particular, > > > > I suggest not to use section numbers in issues, because they obviously > change over time, moreover, if we use section numbers, we have a strong > incentive to keep them from one version to the next and it's way too early > for that. > > > > Thanks, > > Yaron > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000007eb93a05b3ffd88f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yaron,=C2=A0

That's right, but w= e need to find a way to identify where the issue is located.=C2=A0
For editor's notes, Justin has worked in the other direction : issues= are refered from the spec itself.=C2=A0=C2=A0
But we might not w= ant to change the spec each time we have an issue, so I don't know what= 's the best solution here.

Cheers
Fa= bien

On Fri, Nov 13, 2020 at 4:56 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi everyone= , editors in particular,

=C2=A0

I suggest not to use section numbers = in issues, because they obviously change over time, moreover, if we use sec= tion numbers, we have a strong incentive to keep them from one version to t= he next and it's way too early for that.

=C2=A0=

Thanks,=

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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000007eb93a05b3ffd88f-- From nobody Fri Nov 13 08:55: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 7EE6A3A0F0B for ; Fri, 13 Nov 2020 08:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CjcoZtQ57Pui for ; Fri, 13 Nov 2020 08:55:01 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382CC3A0F06 for ; Fri, 13 Nov 2020 08:55:00 -0800 (PST) Received: from [192.168.1.19] (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 0ADGsx8C003229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 13 Nov 2020 11:54:59 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_25E3CD09-DBA5-4EFA-B45D-11A1C5CD1B4F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <5A869026-7AA4-4F72-B9C2-63B40C986EF2@mit.edu> Date: Fri, 13 Nov 2020 11:54:59 -0500 To: GNAP Mailing List X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [GNAP] Extraction of Editor's Notes 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, 13 Nov 2020 16:55:04 -0000 --Apple-Mail=_25E3CD09-DBA5-4EFA-B45D-11A1C5CD1B4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The editors have gone through the draft document and extracted all of = the existing =E2=80=9CEditor=E2=80=99s Note=E2=80=9D items from the text = and turned them into discrete GitHub issues for discussion. Several = closely-related notes were collapsed into single issues. Apart from = fixing a couple typos or adding context from surrounding text, the text = of the editor=E2=80=99s note was pulled verbatim from the document into = GitHub. These are all in the project repository=E2=80=99s issue tracker: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues = A pull request has been submitted that removes the editor=E2=80=99s note = and replaces it with a link to the corresponding GitHub issue: https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/119 = Each issue=E2=80=99s text contains the current section number and title = that the text was extracted from in order to facilitate people finding = the appropriate context in which the notes were originally written. = However, do note that as Yaron posted to the list earlier today, in = general we don=E2=80=99t want to have to refer to things in GitHub = issues by section number, since the section numbers can and will change = over time as the document evolves. Therefore future issues should avoid = including section numbers, and must not rely on section numbers as the = only content reference pointer. This extraction was done to facilitate ongoing conversation on each of = the items raised by the notes. Notational text in the document itself is = necessarily static, and it can=E2=80=99t incorporate multiple = perspectives and opinions. Moving these items to GitHub issues will = allow others to comment on the issue directly to provide their own = opinions, input, and contexts; and ultimately for the working group to = arrive to consensus and drive document changes from these discussions. The editors will eventually remove the issue references from the spec as = things are closed, and we won=E2=80=99t necessarily be adding links to = new issues into the draft spec going forward unless there is a = compelling reason for it like an ongoing discussion for options or a = major design change. =E2=80=94 Justin, Fabien, and Aaron= --Apple-Mail=_25E3CD09-DBA5-4EFA-B45D-11A1C5CD1B4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = editors have gone through the draft document and extracted all of the = existing =E2=80=9CEditor=E2=80=99s Note=E2=80=9D items from the text and = turned them into discrete GitHub issues for discussion. Several = closely-related notes were collapsed into single issues. Apart from = fixing a couple typos or adding context from surrounding text, the text = of the editor=E2=80=99s note was pulled verbatim from the document into = GitHub. These are all in the project repository=E2=80=99s issue = tracker:

=
[FI] delegation from a RS to anot= her is a topic in itself, yet to be explored. I remember you sent various i= nputs on that, we might need to review them in detail.=C2=A0
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues

A pull request = has been submitted that removes the editor=E2=80=99s note and replaces = it with a link to the corresponding GitHub issue:

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

Each issue=E2=80=99s text contains the current section number = and title that the text was extracted from in order to facilitate people = finding the appropriate context in which the notes were originally = written. However, do note that as Yaron posted to the list earlier = today, in general we don=E2=80=99t want to have to refer to things in = GitHub issues by section number, since the section numbers can and will = change over time as the document evolves. Therefore future issues should = avoid including section numbers, and must not rely on section numbers as = the only content reference pointer.

This extraction was done to facilitate = ongoing conversation on each of the items raised by the notes. = Notational text in the document itself is necessarily static, and it = can=E2=80=99t incorporate multiple perspectives and opinions. Moving = these items to GitHub issues will allow others to comment on the issue = directly to provide their own opinions, input, and contexts; and = ultimately for the working group to arrive to consensus and drive = document changes from these discussions.

The editors will eventually remove the = issue references from the spec as things are closed, and we won=E2=80=99t = necessarily be adding links to new issues into the draft spec going = forward unless there is a compelling reason for it like an ongoing = discussion for options or a major design change.

 =E2=80=94 Justin, Fabien, and = Aaron
= --Apple-Mail=_25E3CD09-DBA5-4EFA-B45D-11A1C5CD1B4F-- From nobody Fri Nov 13 14: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 63E2C3A0D95 for ; Fri, 13 Nov 2020 14:25:46 -0800 (PST) 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 TcoQVBMA8lph for ; Fri, 13 Nov 2020 14:25:44 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0203A0D9A for ; Fri, 13 Nov 2020 14:25:43 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id c17so11784505wrc.11 for ; Fri, 13 Nov 2020 14:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=XTs7wEfJddcUHCkSppDQLZjmikAARZXluj4DC22fDfI=; b=Z793fjRUa16T/XvFtaJtyj5LpJMeAwf0CsNWyazAwvlbm6+DGtb4OLyetixXWbI5Qz bo+sxHy8g6q7rFjk1wFdO5zWT2xyjiL65zOQeF/k0h8tBhaDFy8nq8jZZzKwLzpBs8HL E9AEzPyLKsF0znw3pwXVFc7LljOFis8R+1ImxRhW3EQevN5bvY1A6UH54n0GaVnbb0s+ sxWxDNSakX00jN8rp4lxndqXQXRcO8qkwiljo0CwNM9UiM/jv5shktZ/We/w0V8aG7yA Gy+AwVXLVyt4m6t3dhSiURLFVd4KtXbYS/IPGj45e+bo1A1Gm5626r1rrxlcYEQClDb4 eviw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=XTs7wEfJddcUHCkSppDQLZjmikAARZXluj4DC22fDfI=; b=sqxxH4Z+Z8fSdm5cdWDnpUE8iehsTxCy55nbbL281LBRTlVCAmw1SBVXipd8elDxBl hDf6NG/iXGGs/upsSHciqzEQlt8BaA+lPbTb5fBXS6MOtDHNAUOwD3fuaD7/ITMGm69k oK1VycVymQBofyjsJ6fotjzZPqKXnjprGrNaOi4T+sJXG/6PRev+vr+wipmbwgmlBX8x kGOf2aYuorVsk+1fLHqoDiUY0rTS1Xzedkss4VY9aZkkxRXVHYndEaqOJ7BN4Bh5u6Ep krh7dKy10MsfmRLlzP293nrpa0smTInydzwppLViebU4lPhhTfv+Ak2NtkpytLlbFiiv /fbQ== X-Gm-Message-State: AOAM531R2Q5eiOmLLODRmF3/RilGq8E2jt8SSxLCZzR0I66FDL4hshFq GvOtd47gx63iNL1iKrkF+MI= X-Google-Smtp-Source: ABdhPJw8a3dqbynO7+r8l4tfLr1GXblBKuBCLK98jp+zWuvVhGWDhr4598evfb+Q0Cbq8nlVxcbYdw== X-Received: by 2002:a5d:5701:: with SMTP id a1mr5976080wrv.120.1605306341773; Fri, 13 Nov 2020 14:25:41 -0800 (PST) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id b14sm12045032wrq.47.2020.11.13.14.25.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2020 14:25:41 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Sat, 14 Nov 2020 00:25:40 +0200 From: Yaron Sheffer To: Fabien Imbault CC: GNAP Mailing List Message-ID: <087811AB-E85E-4B78-BB8C-E136905514BB@gmail.com> Thread-Topic: [GNAP] Another process comment - section numbers in issues References: <664DC2D5-350A-4795-AC15-18EBA7CB4D25@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688158340_443472712" Archived-At: Subject: Re: [GNAP] Another process comment - section numbers in issues 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, 13 Nov 2020 22:25:47 -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_3688158340_443472712 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Fabien, =20 I would quote the full text of the section title, instead of its number. Ug= ly but practical. =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: Fabien Imbault Date: Friday, November 13, 2020 at 18:51 To: Yaron Sheffer Cc: GNAP Mailing List Subject: Re: [GNAP] Another process comment - section numbers in issues =20 Hi Yaron,=20 =20 That's right, but we need to find a way to identify where the issue is loca= ted.=20 For editor's notes, Justin has worked in the other direction : issues are r= efered from the spec itself. =20 But we might not want to change the spec each time we have an issue, so I d= on't know what's the best solution here. =20 Cheers Fabien =20 On Fri, Nov 13, 2020 at 4:56 PM Yaron Sheffer wrote= : Hi everyone, editors in particular, =20 I suggest not to use section numbers in issues, because they obviously chan= ge over time, moreover, if we use section numbers, we have a strong incentiv= e to keep them from one version to the next and it's way too early for that. =20 Thanks, Yaron --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --B_3688158340_443472712 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Fabien,=

 

I would quote= the full text of the section title, instead of its number. Ugly but practic= al.

 

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

 

From: Fabien Imbault <fabien.imbault@gmail.= com>
Date: Friday, November 13, 2020 at 18:51
To: Yar= on Sheffer <yaronf.ietf@gmail.com>
Cc: GNAP Mailing List <= ;txauth@ietf.org>
Subject: Re: [GNAP] Another process comment -= section numbers in issues

 

Hi Yaron, 

 

That's right, but we need to find a way to identify where the issue is= located. 

For editor's not= es, Justin has worked in the other direction : issues are refered from the s= pec itself.  

But we m= ight not want to change the spec each time we have an issue, so I don't know= what's the best solution here.

=  

Cheers

Fabien

 

On Fri, Nov 13, 2020 at = 4:56 PM Yaron Sheffer <yaronf.ietf= @gmail.com> wrote:

Hi everyone, editors in particular,

 

I suggest not to use section numbers in issues= , because they obviously change over time, moreover, if we use section numbe= rs, we have a strong incentive to keep them from one version to the next and= it's way too early for that.

 

Thanks,=

          = ;      Yaron

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

--B_3688158340_443472712-- From nobody Sat Nov 14 23:51: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 1421F3A0A47 for ; Sat, 14 Nov 2020 23:51:06 -0800 (PST) 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_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=mnot.net header.b=ECeMfC2J; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=j7zT0qKk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2zr3M3l8f89 for ; Sat, 14 Nov 2020 23:51:01 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E523A0A42 for ; Sat, 14 Nov 2020 23:51:01 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 55E8A9C4 for ; Sun, 15 Nov 2020 02:32:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 15 Nov 2020 02:32:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=PkqDlDAqd5yxBB4AV4XMt0j1KAfW6Fc4fU0rqso4zgc=; b=ECeMfC2J poc6dD+4UzsJid+ZGTggBLCu9Fb7lCMAaa8e+03tE9O/OL8w9Y7C0fI9KhgaqRDE nK5m5HMG2Zp457PgoQpqyV6q+JB2wSll7qnuO+fRNBll0+dD3hTeOp7+Nl95Pf7D diTAi/qj4VbdREdbYml9bCUUw0u3P5dnTZIRbMt4tCElBj4nc06TWnO84/ZEtpyk UkqGl3Ci3XplgHG874pCP+ZKkBagwarpRStJpyuSAHr89o1somTmgEdSv5KbPMGa 9yew1z2YXipXZRp6PX8hsTVlSlym5jS+VIzd9BTkRdXhsj0qaLKDWId7oFU5jn9j h72yMc19EbDoMQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=PkqDlDAqd5yxBB4AV4XMt0j1KAfW6 Fc4fU0rqso4zgc=; b=j7zT0qKkw5ROA8x18H+3KFPQ/QBZYAG/ernNIFnxaBvZs E8DWbtOsSmdWjoX0BDxkqVMYhvwVkQ9XyhXBr0cwVdqBvf5RZfEDnmpt1z19pepz M8u92M04lNo5jsuSblO5W4ijEFwbnnnKvo0P71UI0ArgbSRXTLLuoDEpNJQeH+/g Q0TaHU9EAyg2064r/kqYZtF3VTk2CKAGQMt48luytu0r9SXbqT1HLGrF36Sw0Fnl wBVeyRc9Bcr/NyuQs1DnmRTLCTYABerMEYUwEaG+sSLpOCwZC9qFlRAcHwXGPwlI 7IkhA3vKV8Kbz22sEUDeO640KdHz80lXQ7GfW977w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvkedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedutdegrddvtdelrddufe elrdduheejnecuvehluhhsthgvrhfuihiivgepgeenucfrrghrrghmpehmrghilhhfrhho mhepughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az60-705.internal.cloudapp.net (unknown [104.209.139.157]) by mail.messagingengine.com (Postfix) with ESMTPA id AA91F3280059 for ; Sun, 15 Nov 2020 02:32:50 -0500 (EST) Content-Type: multipart/alternative; boundary="===============0528121766924297519==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20201115073250.AA91F3280059@mailuser.nyi.internal> Date: Sun, 15 Nov 2020 02:32:50 -0500 (EST) 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, 15 Nov 2020 07:51:06 -0000 --===============0528121766924297519== 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 (+91/-1/=F0=9F=92=AC27) 91 issues created: - Redirect to an Arbitrary Shortened URL (by davidgtonge) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/121=20 - RS www-authenticate response (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/118=20 - RS-registered resource reference handle arity (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/117=20 - RS Token derivation (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116=20 - Token Introspection (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115=20 - Resource Server Section (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/114=20 - Applicability of OAuth PoP (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/113=20 - Use of OAuth PoP without access tokens (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/112=20 - Key redundancy in DPoP method (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/111=20 - Validation of MTLS signature method (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/110=20 - Modification of content type by attached JWS signature method (by jrich= er) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109=20 - Fragility of JOSE-based signature methods (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/108=20 - Detached-JWS header (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/107=20 - JWS Headers for JOSE-based signature methods (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/106=20 - Rotation of bound client keys (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105=20 - Token presentation headers (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/104=20 - Rotating the token's bound key (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/103=20 - Require inclusion of token management URI in rotation response (by jric= her) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/102=20 - Invalidating previous access tokens during rotation (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/101=20 - HTTP PUT vs POST for rotating access tokens (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100=20 - Updating and reading access tokens (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/99=20 - Reading the state of a request (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/98=20 - Interaction requests as one-time-use (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/97=20 - Revoking existing access tokens on modification (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/96=20 - Inclusion of post-interaction items in a modification (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/95=20 - Exclusion of "client" field in a modification (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/94=20 - Inclusion of the "user" field in a modification (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/93=20 - Enforcing modification of a request (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/92=20 - Communicating User State During Pending Interaction (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/91=20 - Contents of follow-in continue response (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/90=20 - Multi-step interaction methods (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/89=20 - Combining post-interaction updates (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/88=20 - Rotation of continuation access tokens (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87=20 - Default polling wait time (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/86=20 - Key rotation within continuation (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/85=20 - Use of hash with unique callback URL (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84=20 - Additional post-interaction protocols (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83=20 - Application communication with back-end (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82=20 - Interaction considerations (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81=20 - Response Extensions (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/80=20 - Error responses (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/79=20 - Dynamic RC instance management (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/78=20 - Dynamic RC instance registration (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/77=20 - Expandng dynamic reference handles (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76=20 - Scope of subject identifiers (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/75=20 - Privacy considerations of returned user information (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/74=20 - Post interaction callback nonce (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73=20 - Separation of AS into delegation and interaction (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/72=20 - Expand the application launch response (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/71=20 - Uniqueness of Token Management URIs (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/70=20 - Directed access tokens (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69=20 - Syntax for single and multiple access tokens (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/68=20 - Continuation API artifact structure (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/67=20 - Continuation access token use outside of continuation requests (by jric= her) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/66=20 - Guidance for Grant Request Extensions (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/65=20 - Including OpenID Connect claims (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64=20 - Splitting the "claims" request (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/63=20 - Referencing an existing grant request (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/62=20 - Provide guidance for defining new interactions (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/61=20 - Push-based post-interaction hook (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/60=20 - Post-interaction callback bundling (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/59=20 - Post-interaction static page (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/58=20 - Identification of Hash Algorithms (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/57=20 - Hash algorithm identifiers (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/56=20 - Unique callback URIs (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55=20 - Application-specific URL (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/54=20 - Error mode for short interaction URL (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/53=20 - Create more examples of interaction modes (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/52=20 - User reference as an assertion (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/51=20 - User identification items (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/50=20 - AS Validation of RC-presented assertions (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/49=20 - Logo by value (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/48=20 - Fetchable keys (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47=20 - Instance Identifier (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46=20 - Mutual exclusivity of instance identifier (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/45=20 - Client attestation and posture (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44=20 - User information request items (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/43=20 - Use of identifiers as communication channels (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/42=20 - Assertion format names (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/41=20 - Access token request format (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/40=20 - Token flags (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/39=20 - "bind_token" flag and functionality (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/38=20 - "split_token" functionality and flag (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/37=20 - Requesting resources by reference (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36=20 - Mapping resource references (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35=20 - Alignment with RAR (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/34=20 - Non-role protocol elements (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/33=20 - Names for Roles (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/32=20 - Asynchronous Authorization (by davidgtonge) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/31=20 - Structure of the spec (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30=20 - Terminology (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29=20 9 issues received 27 new comments: - #121 Redirect to an Arbitrary Shortened URL (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/121=20 - #60 Push-based post-interaction hook (1 by davidgtonge) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/60=20 - #57 Identification of Hash Algorithms (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/57=20 - #31 Asynchronous Authorization (6 by davidgtonge, fimbault, jricher, ya= ronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/31=20 - #29 Terminology (11 by TomCJones, dickhardt, fimbault, francis-pouatcha= , jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29=20 - #21 The App Option (4 by davidgtonge, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/21=20 - #20 Interaction "Modes" (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/20=20 - #15 Token Binding (1 by davidgtonge) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/15=20 - #6 Polymorphism (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/6=20 1 issues closed: - Identification of Hash Algorithms https://github.com/ietf-wg-gnap/gnap-= core-protocol/issues/57=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+2/-1/=F0=9F=92=AC0) 2 pull requests submitted: - Minor cleanup, fix dangling statement. (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/120=20 - Moved editor's notes to external GitHub issues (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/119=20 1 pull requests merged: - Moved editor's notes to external GitHub issues https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/119=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============0528121766924297519== 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 November 15, 2020

Events without label "editorial"

Issues

ietf-wg-gnap/core-protocol (+91/-1/=F0=9F=92=AC27)

91 issues created:

9 issues received 27 new comments:

1 issues closed:

Pull requests

ietf-wg-gnap/core-protocol (+2/-1/=F0=9F=92=AC0)

2 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============0528121766924297519==-- From nobody Mon Nov 16 02:06: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 78A593A16BD for ; Mon, 16 Nov 2020 02:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, T_KAM_HTML_FONT_INVALID=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=moneyhub.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 s6pjwyPrvkEe for ; Mon, 16 Nov 2020 02:06:42 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 44AF93A174B for ; Mon, 16 Nov 2020 02:06:40 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id f23so23629395ejk.2 for ; Mon, 16 Nov 2020 02:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FTYKqW7M/fpx9omSk1HdgfjFLsZ6Bb25RW4tW6t9djw=; b=MrvzH4Ura01HMjSYxv0RR1RgCJ11FobMJB0fv4JR3uKkdLCZp/gLRFXJM61frPmoeP IaB3HhM/OMUFzJ2EPOTQSeSU4jPviaQZat+FBnYxFIsueXd7uI2ulDblg+6zse9wZIPp 5ugxpgYKmvUJHxt+jIJ+1CTumtcIiEC6w+U3Q= 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=FTYKqW7M/fpx9omSk1HdgfjFLsZ6Bb25RW4tW6t9djw=; b=i1F9UVhengaN9K4WXRg9WnahIAuO679iqixI9GWlztYXqmVVggjjPLoE9y0GQLmvW6 4Q9k7H9kBQ0WipicJ6uhKrC13/U20BkOlfDp1QFFycxS/ea89qQMKTzCZG0doD1dLnK1 dMyhHedGKw+cbm7YQi5BquqoJIUo3w4Sxq5BrpKtPs9+ETQXsB0iDpIoBxKUhOFhqwLH uNIncUPr3Kmdw9ZPE0OXsJWp+LPV1lCeJ1SNOIuByyr+9J7rkhVnu9gDzJraQq8VjZmE 2SWzloAO43k4S7lNuoSS5ih4SoSdQOMhU0w4h1hOE41Oi1H6SiJCVN4wrK3GjyP5FgAs YMFQ== X-Gm-Message-State: AOAM533i4JsG8jKd3p5yG/PrD/wrgwxuC1gcmUnbmpK7Yo2ho9c3l4QE szHzxLadkF+aLjGVcIRQROFAIVXhS38H5EzzAgpVK6+W7lfKg+jHN6j+RYZLvK1MKSqQTP/BRp3 l7BybT13qDkuoBc3tA0ZU1R6n1w== X-Google-Smtp-Source: ABdhPJwqYBHBXBSySC2GF1iWNOqDtACiLBvcv8YQXGT8e/Sn5pB7xSLzFM6i+8+iClZ01M/mEt4tcSLqNu6SzwwBCOM= X-Received: by 2002:a17:906:3958:: with SMTP id g24mr14090415eje.360.1605521198279; Mon, 16 Nov 2020 02:06:38 -0800 (PST) MIME-Version: 1.0 References: <5A869026-7AA4-4F72-B9C2-63B40C986EF2@mit.edu> In-Reply-To: <5A869026-7AA4-4F72-B9C2-63B40C986EF2@mit.edu> From: Dave Tonge Date: Mon, 16 Nov 2020 11:06:27 +0100 Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000b40a1905b4368885" Archived-At: Subject: Re: [GNAP] Extraction of Editor's Notes 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: Mon, 16 Nov 2020 10:06:45 -0000 --000000000000b40a1905b4368885 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI Editors Just a quick question - there are a lot of issues. Would you like WG members to comment on each issue? Also what is the process on closing an issue, it would be good to get some issues closed, or else I fear that we will be stuck with 100+ issues for a considerable amount of time. Dave On Fri, 13 Nov 2020 at 17:55, Justin Richer wrote: > The editors have gone through the draft document and extracted all of the > existing =E2=80=9CEditor=E2=80=99s Note=E2=80=9D items from the text and = turned them into discrete > GitHub issues for discussion. Several closely-related notes were collapse= d > into single issues. Apart from fixing a couple typos or adding context fr= om > surrounding text, the text of the editor=E2=80=99s note was pulled verbat= im from > the document into GitHub. These are all in the project repository=E2=80= =99s issue > tracker: > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues > > A pull request has been submitted that removes the editor=E2=80=99s note = and > replaces it with a link to the corresponding GitHub issue: > > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/119 > > Each issue=E2=80=99s text contains the current section number and title t= hat the > text was extracted from in order to facilitate people finding the > appropriate context in which the notes were originally written. However, = do > note that as Yaron posted to the list earlier today, in general we don=E2= =80=99t > want to have to refer to things in GitHub issues by section number, since > the section numbers can and will change over time as the document evolves= . > Therefore future issues should avoid including section numbers, and must > not rely on section numbers as the only content reference pointer. > > This extraction was done to facilitate ongoing conversation on each of th= e > items raised by the notes. Notational text in the document itself is > necessarily static, and it can=E2=80=99t incorporate multiple perspective= s and > opinions. Moving these items to GitHub issues will allow others to commen= t > on the issue directly to provide their own opinions, input, and contexts; > and ultimately for the working group to arrive to consensus and drive > document changes from these discussions. > > The editors will eventually remove the issue references from the spec as > things are closed, and we won=E2=80=99t necessarily be adding links to ne= w issues > into the draft spec going forward unless there is a compelling reason for > it like an ongoing discussion for options or a major design change. > > =E2=80=94 Justin, Fabien, and Aaron > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ *. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2019 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --000000000000b40a1905b4368885 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI Editors

Just a quick=C2= =A0question - there are a lot of issues. Would you like WG members to comme= nt on each issue?=C2=A0
Also what is the process on closing an issue, = it would be good to get some issues closed, or else I fear that we will be = stuck with 100+ issues for a considerable amount of time.

=
= Dave

On Fri, 13 Nov 2020 at 17:55, Justin Richer <jricher@mit.edu> wrote:
The editors have go= ne through the draft document and extracted all of the existing =E2=80=9CEd= itor=E2=80=99s Note=E2=80=9D items from the text and turned them into discr= ete GitHub issues for discussion. Several closely-related notes were collap= sed into single issues. Apart from fixing a couple typos or adding context = from surrounding text, the text of the editor=E2=80=99s note was pulled ver= batim from the document into GitHub. These are all in the project repositor= y=E2=80=99s issue tracker:


A pu= ll request has been submitted that removes the editor=E2=80=99s note and re= places it with a link to the corresponding GitHub issue:

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

Each issue=E2=80=99s text contains the c= urrent section number and title that the text was extracted from in order t= o facilitate people finding the appropriate context in which the notes were= originally written. However, do note that as Yaron posted to the list earl= ier today, in general we don=E2=80=99t want to have to refer to things in G= itHub issues by section number, since the section numbers can and will chan= ge over time as the document evolves. Therefore future issues should avoid = including section numbers, and must not rely on section numbers as the only= content reference pointer.

This extraction was do= ne to facilitate ongoing conversation on each of the items raised by the no= tes. Notational text in the document itself is necessarily static, and it c= an=E2=80=99t incorporate multiple perspectives and opinions. Moving these i= tems to GitHub issues will allow others to comment on the issue directly to= provide their own opinions, input, and contexts; and ultimately for the wo= rking group to arrive to consensus and drive document changes from these di= scussions.

The editors will eventually remov= e the issue references from the spec as things are closed, and we won=E2=80= =99t necessarily be adding links to new issues into the draft spec going fo= rward unless there is a compelling reason for it like an ongoing discussion= for options or a major design change.

=C2=A0=E2= =80=94 Justin, Fabien, and Aaron
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--
Dave Tonge
CTO
3D"Moneyhub
Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t:= =C2=A0+44 (0)117= 280 5120

Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--000000000000b40a1905b4368885-- From nobody Mon Nov 16 02:13: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 250FD3A16D1 for ; Mon, 16 Nov 2020 02:13:27 -0800 (PST) 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=[AC_DIV_BONANZA=0.001, 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 sjuqfbicKR5y for ; Mon, 16 Nov 2020 02:13:24 -0800 (PST) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 780213A16F7 for ; Mon, 16 Nov 2020 02:13:02 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id cw8so23567448ejb.8 for ; Mon, 16 Nov 2020 02:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=utpbwh7RVAhuRsk3OaJatpa8fcwE2AWd+IEeheeZ0Lc=; b=p9R3kY17a8WIP0+mZmgtZ1Zuyy+ZSeKUoc1vQaR7ZLBAtFJvsWbr+J0L4E107KLsoX rvey7tqaxpsSViku2kVBMWClP0+0/nptJtJHvtrVycM2jEPUclsEy09ZZ1F7Zldy7Hzk p0E+XekZFJsQvu7IJ8oXiGOZsBQc0z4dTkzU0Zkn6Ppeuj9TvbA0e876BfwbG/zPBnag av/9IbwdxPt5OnvwzvU/3Ii5crfJj7j7aQHDJgzMjKZW1XHVKiJwpd3m0aFKYccSh90O VGVF3c3kPQ0tAmkJIh6KESraGZ3qJt4ogKCT59SdT1hqziaUr8IbUxQc7yCMYC8g8fHS /8/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:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=utpbwh7RVAhuRsk3OaJatpa8fcwE2AWd+IEeheeZ0Lc=; b=gx73LB6qiIEGrwbDDa410PTG1WEBitxfQPXipxt+EKBn8rux8Tfwu3RFeV9eiOvsvQ LO9ntcT6LCrM8g9S8rcSQHuc8u4bOwWq/LKIGubhDCE0kkaBHcdKAInnOSblYzCKW4Ft ijUI8TTuHjpeDSuAJdPyNgxhBF6lKJe+8fY4Q+uGHtnWzXkdPDMRd68UvwykCLltjWhx rq+bb49D2aszCt3Wlj+6imMvtckFkhXlTbJfIKyKvADkmLxnLrQx1KuWt02Ub2S1U/rw 08+OzgcYisTGzwgWhr2Xk9EL0uAHRulkEo3dJtoQ8vpvixzjE7SMuyaULKlDqNxVcLx/ vXCQ== X-Gm-Message-State: AOAM532zsGgbJGKNR7L98HEHheeqIiNHGkCJhul1QQ2a4GYW6A8oVxwt Y90AbfelN5o4FhLkpVZ49xYfJtmtDjc= X-Google-Smtp-Source: ABdhPJzgpZVTrPOmY+fIwfkkrX8nS4AvysV94zllKbV/5ALzXPC8uYeUmUgLpmwceAWZkiQzYiyMlw== X-Received: by 2002:a17:906:d20e:: with SMTP id w14mr14078692ejz.479.1605521580923; Mon, 16 Nov 2020 02:13:00 -0800 (PST) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id j6sm10514691edy.87.2020.11.16.02.12.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2020 02:13:00 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Mon, 16 Nov 2020 12:12:58 +0200 From: Yaron Sheffer To: Dave Tonge , Justin Richer CC: GNAP Mailing List Message-ID: Thread-Topic: [GNAP] Extraction of Editor's Notes References: <5A869026-7AA4-4F72-B9C2-63B40C986EF2@mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688373579_1802674833" Archived-At: Subject: Re: [GNAP] Extraction of Editor's Notes 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: Mon, 16 Nov 2020 10:13:27 -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_3688373579_1802674833 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Process discussion coming up tomorrow, https://datatracker.ietf.org/meeting= /109/materials/slides-109-gnap-process-proposal-00 =20 Please note though that we will be strict on time =E2=80=93 it=E2=80=99s just too easy = to spend the meeting on process and never get to the protocol discussion. =20 Spoiler: yes, please comment on the issues (you don=E2=80=99t have to comment on = all 100=E2=80=A6). =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 Dave Tonge Date: Monday, November 16, 2020 at 12:06 To: Justin Richer Cc: GNAP Mailing List Subject: Re: [GNAP] Extraction of Editor's Notes =20 HI Editors =20 Just a quick question - there are a lot of issues. Would you like WG member= s to comment on each issue?=20 Also what is the process on closing an issue, it would be good to get some = issues closed, or else I fear that we will be stuck with 100+ issues for a c= onsiderable amount of time. =20 Dave =20 On Fri, 13 Nov 2020 at 17:55, Justin Richer wrote: The editors have gone through the draft document and extracted all of the e= xisting =E2=80=9CEditor=E2=80=99s Note=E2=80=9D items from the text and turned them into discr= ete GitHub issues for discussion. Several closely-related notes were collaps= ed into single issues. Apart from fixing a couple typos or adding context fr= om surrounding text, the text of the editor=E2=80=99s note was pulled verbatim fro= m the document into GitHub. These are all in the project repository=E2=80=99s issu= e tracker: =20 https://github.com/ietf-wg-gnap/gnap-core-protocol/issues =20 A pull request has been submitted that removes the editor=E2=80=99s note and repl= aces it with a link to the corresponding GitHub issue: =20 https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/119 =20 Each issue=E2=80=99s text contains the current section number and title that the = text was extracted from in order to facilitate people finding the appropriat= e context in which the notes were originally written. However, do note that = as Yaron posted to the list earlier today, in general we don=E2=80=99t want to hav= e to refer to things in GitHub issues by section number, since the section n= umbers can and will change over time as the document evolves. Therefore futu= re issues should avoid including section numbers, and must not rely on secti= on numbers as the only content reference pointer. =20 This extraction was done to facilitate ongoing conversation on each of the = items raised by the notes. Notational text in the document itself is necessa= rily static, and it can=E2=80=99t incorporate multiple perspectives and opinions. = Moving these items to GitHub issues will allow others to comment on the issu= e directly to provide their own opinions, input, and contexts; and ultimatel= y for the working group to arrive to consensus and drive document changes fr= om these discussions. =20 The editors will eventually remove the issue references from the spec as th= ings are closed, and we won=E2=80=99t necessarily be adding links to new issues in= to the draft spec going forward unless there is a compelling reason for it l= ike an ongoing discussion for options or a major design change. =20 =E2=80=94 Justin, Fabien, and Aaron --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 --=20 Dave Tonge CTO Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 =20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority ("= FCA"). Moneyhub Financial Technology is entered on the Financial Services Re= gister (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Tech= nology is registered in England & Wales, company registration number 069097= 72 . Moneyhub Financial Technology Limited 2019 =C2=A9 =20 DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any info= rmation in it other than by the addressee is unauthorised and unlawful. Whil= st reasonable efforts are made to ensure that any attachments are virus-free= , it is the recipient's sole responsibility to scan all attachments for viru= ses. All calls and emails to and from this company may be monitored and reco= rded for legitimate purposes relating to this company's business. Any opinio= ns expressed in this email (or in any attachments) are those of the author a= nd do not necessarily represent the opinions of Moneyhub Financial Technolog= y Limited or of any other group company. =20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority ("= FCA"). Moneyhub Financial Technology is entered on the Financial Services Re= gister (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Tech= nology is registered in England & Wales, company registration number 0690977= 2. Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus = Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=20 DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any info= rmation in it other than by the addressee is unauthorised and unlawful. Whil= st reasonable efforts are made to ensure that any attachments are virus-free= , it is the recipient's sole responsibility to scan all attachments for viru= ses. All calls and emails to and from this company may be monitored and reco= rded for legitimate purposes relating to this company's business. Any opinio= ns expressed in this email (or in any attachments) are those of the author a= nd do not necessarily represent the opinions of Moneyhub Financial Technolog= y Limited or of any other group company. -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3688373579_1802674833 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Process discussion coming up tomorrow, https://datatr= acker.ietf.org/meeting/109/materials/slides-109-gnap-process-proposal-00=

 

Pl= ease note though that we will be strict on time =E2=80=93 it=E2=80=99s just too easy to = spend the meeting on process and never get to the protocol discussion.<= /o:p>

 

Spoiler:= yes, please comment on the issues (you don=E2=80=99t have to comment on all 100=E2=80= =A6).

 

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

 

From: TXAuth <txauth-bounces@ietf.org> o= n behalf of Dave Tonge <dave.tonge@moneyhub.com>
Date: Monda= y, November 16, 2020 at 12:06
To: Justin Richer <jricher@mit.ed= u>
Cc: GNAP Mailing List <txauth@ietf.org>
Subject:= Re: [GNAP] Extraction of Editor's Notes

 

HI Editors

 

Just a quick quest= ion - there are a lot of issues. Would you like WG members to comment on eac= h issue? 

Also what is the process on closin= g an issue, it would be good to get some issues closed, or else I fear that = we will be stuck with 100+ issues for a considerable amount of time.

 

Dave=

 

On Fri, 13 Nov 2020 at 17:55, Justin Richer <jricher@mit.edu> wrote:

<= /div>

The editors have gone through the draft document and extracted all of the = existing =E2=80=9CEditor=E2=80=99s Note=E2=80=9D items from the text and turned them into disc= rete GitHub issues for discussion. Several closely-related notes were collap= sed into single issues. Apart from fixing a couple typos or adding context f= rom surrounding text, the text of the editor=E2=80=99s note was pulled verbatim fr= om the document into GitHub. These are all in the project repository=E2=80=99s iss= ue tracker:

 

 

A pull request has been submitted that= removes the editor=E2=80=99s note and replaces it with a link to the correspondin= g GitHub issue:

 

<= /div>

=  

Each issue=E2=80=99s text conta= ins the current section number and title that the text was extracted from in= order to facilitate people finding the appropriate context in which the not= es were originally written. However, do note that as Yaron posted to the lis= t earlier today, in general we don=E2=80=99t want to have to refer to things in Gi= tHub issues by section number, since the section numbers can and will change= over time as the document evolves. Therefore future issues should avoid inc= luding section numbers, and must not rely on section numbers as the only con= tent reference pointer.

&nb= sp;

This extraction was done to facil= itate ongoing conversation on each of the items raised by the notes. Notatio= nal text in the document itself is necessarily static, and it can=E2=80=99t incorp= orate multiple perspectives and opinions. Moving these items to GitHub issue= s will allow others to comment on the issue directly to provide their own op= inions, input, and contexts; and ultimately for the working group to arrive = to consensus and drive document changes from these discussions.

 

The editors will eventually remove the issue references from th= e spec as things are closed, and we won=E2=80=99t necessarily be adding links to n= ew issues into the draft spec going forward unless there is a compelling rea= son for it like an ongoing discussion for options or a major design change.<= o:p>

 

=

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

<= /div>

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/txauth

=

 

--

=

Dave Tonge

CTO

3D"=<= /span>

Moneyhub Financial Tec= hnology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL

t: +44 (0)117 280 5120= =

 =

Moneyhub Enterprise is a trading style= of Moneyhub Financial Technology Limited which is authorised and regulated = by the Financial Conduct Authority ("FCA"). Moneyhub Financia= l Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company= registration number  06909772 .

Moneyhub Financial Technology Li= mited 2019 =C2=A9

 

DISCLAIMER: Th= is email (including any attachments) is subject to copyright, and the inform= ation in it is confidential. Use of this email or of any information in it o= ther than by the addressee is unauthorised and unlawful. Whilst reasonable e= fforts are made to ensure that any attachments are virus-free, it is the rec= ipient's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legiti= mate purposes relating to this company's business. Any opinions expressed in= this email (or in any attachments) are those of the author and do not neces= sarily represent the opinions of Moneyhub Financial Technology Limited or of= any other group company.

 

Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fina= ncial Conduct Authority ("FCA"). Moneyhub Financial Technology is = entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Mone= yhub Financial Technology is registered in England & Wales, company regi= stration number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 Mone= yhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.&nb= sp;

DISCLAIMER: This email (including any attachment= s) is subject to copyright, and the information in it is confidential. Use o= f this email or of any information in it other than by the addressee is unau= thorised and unlawful. Whilst reasonable efforts are made to ensure that any= attachments are virus-free, it is the recipient's sole responsibility to sc= an all attachments for viruses. All calls and emails to and from this compan= y may be monitored and recorded for legitimate purposes relating to this com= pany's business. Any opinions expressed in this email (or in any attachments= ) are those of the author and do not necessarily represent the opinions of M= oneyhub Financial Technology Limited or of any other group company.


-- TXAuth mailing list TXAuth@iet= f.org https://www.ietf.org/mailman/listinfo/txauth

--B_3688373579_1802674833-- From nobody Mon Nov 16 02:19: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 06BC83A16CD for ; Mon, 16 Nov 2020 02:19:15 -0800 (PST) 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_KAM_HTML_FONT_INVALID=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 Vj8uNteNyfxB for ; Mon, 16 Nov 2020 02:19:13 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 E597B3A167B for ; Mon, 16 Nov 2020 02:19:12 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id m9so16776769iox.10 for ; Mon, 16 Nov 2020 02:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jZOWvq9bNTVRDbIOOeifsGYLjvRpHxLPxHhvWWdhpCY=; b=H2Y5WKUFuA+4pGYtp6tiq+9y0xzC49oI+MUTGTV4VGGSOpgp/shWch4KcpJ+jeaWQx cNJTuJwzB+ypmPB7PFxzQrzRxRddGcHZIDRfgegAMyt5Z2bF+hMIvcHVqW1jTwQjkJS2 WKJGeG+Ahd043YH27HeVV0INmjTHxbBKTF+wdw8scWz813mNFmhkz/Osdz0x0v0Xv3O3 Z/0pk+BbmgrTqv5GzQ1PHY5aomAqGP5Q2Oei3bkYm17fi09ufCqtxfpy4XRv2Z+nVtXy 4m27kbKaHx7hNAn/9jnRQBmLAlh45/ju6QJddBPvT8DiTtXQXdSGiwx286TZczcBtYEz dbcQ== 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=jZOWvq9bNTVRDbIOOeifsGYLjvRpHxLPxHhvWWdhpCY=; b=HNf8ZFt3qHEn9M3yMo50ZsnJ7FReoX8YllviKo/Rymxj6Th5SxrSs5yLFoRTK+Ilfc F97xyxAnXUvPu9Tz3dhV2WWbv4wZ0MDsWsV46y4HrWSJxDLhJBcts1SKoeWISVxRq8Xb QM6trfvPB9LCd/+C0b+EPycntH7JVBuB1AZmu4xVZx7z40ActcutP8UmiBoatkLtPMG+ ag56viyHe0TVd31N6S1pIPWx6ZWZtB4KaFvVoVjSSxmXuuyzuYQLt6RG7UlO0JHWArvu dhgZjzdAzg2XGIvwjonwIy1UOfsKc06+01rrrqBwyUmK2z7BCYWuf79Z51fVKPJjwn3O Ffkw== X-Gm-Message-State: AOAM531r6FszgeSjA/fcx95EeOQVNsL4zJxbYvRHTWvB2AwbIzsMAaG/ PDSWEqbjswNdF5OP2k4UXevw3JbtEIfczmNDfip2PdTXIQ0= X-Google-Smtp-Source: ABdhPJyERzpHmlpCx3uI9e3ga81OEUQekNM4ii47mhgtaBe3FIpxliBrIFbqSrgXZcIe57XPIn7nhfAZGF7RRQ01rYM= X-Received: by 2002:a5e:c119:: with SMTP id v25mr7564163iol.162.1605521952050; Mon, 16 Nov 2020 02:19:12 -0800 (PST) MIME-Version: 1.0 References: <5A869026-7AA4-4F72-B9C2-63B40C986EF2@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 16 Nov 2020 11:19:00 +0100 Message-ID: To: Dave Tonge Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000a1967305b436b57e" Archived-At: Subject: Re: [GNAP] Extraction of Editor's Notes 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: Mon, 16 Nov 2020 10:19:15 -0000 --000000000000a1967305b436b57e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, That's a very good point. I think it really depends on the issue. Some are more informational (ex: issue #46) and may be closed quickly. The majority requires some work, a few are really around design choices. We probably need to make a bit of triage, in terms of priority and impact. But the goal is certainly to close as much as we can, and avoid the unmanageable backlog. The chairs and editors have initial thoughts of a process, to be discussed. Cheers, Fabien On Mon, Nov 16, 2020 at 11:06 AM Dave Tonge wrote= : > HI Editors > > Just a quick question - there are a lot of issues. Would you like WG > members to comment on each issue? > Also what is the process on closing an issue, it would be good to get som= e > issues closed, or else I fear that we will be stuck with 100+ issues for = a > considerable amount of time. > > Dave > > On Fri, 13 Nov 2020 at 17:55, Justin Richer wrote: > >> The editors have gone through the draft document and extracted all of th= e >> existing =E2=80=9CEditor=E2=80=99s Note=E2=80=9D items from the text and= turned them into discrete >> GitHub issues for discussion. Several closely-related notes were collaps= ed >> into single issues. Apart from fixing a couple typos or adding context f= rom >> surrounding text, the text of the editor=E2=80=99s note was pulled verba= tim from >> the document into GitHub. These are all in the project repository=E2=80= =99s issue >> tracker: >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues >> >> A pull request has been submitted that removes the editor=E2=80=99s note= and >> replaces it with a link to the corresponding GitHub issue: >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/119 >> >> Each issue=E2=80=99s text contains the current section number and title = that the >> text was extracted from in order to facilitate people finding the >> appropriate context in which the notes were originally written. However,= do >> note that as Yaron posted to the list earlier today, in general we don= =E2=80=99t >> want to have to refer to things in GitHub issues by section number, sinc= e >> the section numbers can and will change over time as the document evolve= s. >> Therefore future issues should avoid including section numbers, and must >> not rely on section numbers as the only content reference pointer. >> >> This extraction was done to facilitate ongoing conversation on each of >> the items raised by the notes. Notational text in the document itself is >> necessarily static, and it can=E2=80=99t incorporate multiple perspectiv= es and >> opinions. Moving these items to GitHub issues will allow others to comme= nt >> on the issue directly to provide their own opinions, input, and contexts= ; >> and ultimately for the working group to arrive to consensus and drive >> document changes from these discussions. >> >> The editors will eventually remove the issue references from the spec as >> things are closed, and we won=E2=80=99t necessarily be adding links to n= ew issues >> into the draft spec going forward unless there is a compelling reason fo= r >> it like an ongoing discussion for options or a major design change. >> >> =E2=80=94 Justin, Fabien, and Aaron >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F= L > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ > *. Moneyhub Financial Technology is > registered in England & Wales, company registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a1967305b436b57e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,=C2=A0

That's a = very good point.=C2=A0
I think it really depends on the issue. So= me are more informational (ex: issue #46) and may be closed quickly. The ma= jority requires some work, a few are really around design choices.
We probably need to make a bit of triage, in terms of priority and impact= . But the goal is certainly to close as much as we can, and avoid the unman= ageable backlog.

The chairs and editors have initi= al thoughts of a process, to be discussed.=C2=A0

C= heers,
Fabien

On Mon, Nov 16, 2020 at 11:06 AM Dave Tonge <dave.tonge@moneyhu= b.com> wrote:
HI Editors

Just a quick=C2=A0question - there are a lot o= f issues. Would you like WG members to comment on each issue?=C2=A0
Also what is t= he process on closing an issue, it would be good to get some issues closed,= or else I fear that we will be stuck with 100+ issues for a considerable a= mount of time.

Dave

On Fri, 13 Nov 2020 at 17:55, Justin Richer <jricher@mit.edu> wrote:
The editors h= ave gone through the draft document and extracted all of the existing =E2= =80=9CEditor=E2=80=99s Note=E2=80=9D items from the text and turned them in= to discrete GitHub issues for discussion. Several closely-related notes wer= e collapsed into single issues. Apart from fixing a couple typos or adding = context from surrounding text, the text of the editor=E2=80=99s note was pu= lled verbatim from the document into GitHub. These are all in the project r= epository=E2=80=99s issue tracker:


<= div>A pull request has been submitted that removes the editor=E2=80=99s not= e and replaces it with a link to the corresponding GitHub issue:


Each issue=E2=80=99s text contai= ns the current section number and title that the text was extracted from in= order to facilitate people finding the appropriate context in which the no= tes were originally written. However, do note that as Yaron posted to the l= ist earlier today, in general we don=E2=80=99t want to have to refer to thi= ngs in GitHub issues by section number, since the section numbers can and w= ill change over time as the document evolves. Therefore future issues shoul= d avoid including section numbers, and must not rely on section numbers as = the only content reference pointer.

This extractio= n was done to facilitate ongoing conversation on each of the items raised b= y the notes. Notational text in the document itself is necessarily static, = and it can=E2=80=99t incorporate multiple perspectives and opinions. Moving= these items to GitHub issues will allow others to comment on the issue dir= ectly to provide their own opinions, input, and contexts; and ultimately fo= r the working group to arrive to consensus and drive document changes from = these discussions.

The editors will eventual= ly remove the issue references from the spec as things are closed, and we w= on=E2=80=99t necessarily be adding links to new issues into the draft spec = going forward unless there is a compelling reason for it like an ongoing di= scussion for options or a major design change.

=C2= =A0=E2=80=94 Justin, Fabien, and Aaron
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--
Dave Tonge
CTO
3D"Moneyhub
Moneyhub Financial Technology, 5th Fl= oor, 10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 512= 0

Moneyhub Enterprise is a trading style of Moneyhub Financ= ial Technology Limited which is authorised and regulated by the Financial C= onduct Authority ("FCA").=C2=A0Moneyhub Financial Technology is e= ntered on the Financial Services Register=C2=A0(FRN=C2=A0<= /span>809360) at https://register.fca.org.uk/= . Moneyhub=C2=A0Financial Technology is registered in = England & Wales, company registration number=C2=A0=C2= =A006909772=C2=A0.
Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

DISCLAIMER: This email (including= any attachments) is subject to copyright, and the information in it is con= fidential. Use of this email or of any information in it other than by the = addressee is unauthorised and unlawful. Whilst reasonable efforts are made = to ensure that any attachments are virus-free, it is the recipient's so= le responsibility to scan all attachments for viruses. All calls and emails= to and from this company may be monitored and recorded for legitimate purp= oses relating to this company's business. Any opinions expressed in thi= s email (or in any attachments) are those of the author and do not necessar= ily represent the opinions of Moneyhub Financial Technology Limited or of a= ny other group company.

Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000a1967305b436b57e-- From nobody Mon Nov 16 04:53: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 D7E663A0E6D for ; Mon, 16 Nov 2020 04:53:42 -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 2uwxY7zFDWN8 for ; Mon, 16 Nov 2020 04:53:38 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 05D723A0E6B for ; Mon, 16 Nov 2020 04:53:38 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id j12so17314186iow.0 for ; Mon, 16 Nov 2020 04:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wCuryT3/QM1lSbKoVdZ5y5lJWVro4vBwgKkm7kKbtvs=; b=IuDuurG8DceQGQtDRkTyWiBIiw/O6QxvzKMztl8GE7MbrhlgS8yKQjnAOMkwmBpr8O 0wSTjlL8HRpwZlnE8unSr1dC+COBO1PyJsaUN3wZCheD1spMR/Dqs3hIPyQMSoo1Wykn +MRt6sOntt/nE1FH9MRBCNOmMVPiF0w7/LrvcZaDv/CoO8oIWSbhc/b/P5rcsrsIOIOw Fra5BLChbTWoOEAlwtigg0qIu+dqYhNaLZtChF0bHrc6P/lNqyYPYEIlFlcIkGyrEroQ aKyte41otLP3SzzTur4cpgLHRLY78FdIMhMo0MumAYngAsa5Aiz6w1ZKpchGMx779zJI RCDQ== 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=wCuryT3/QM1lSbKoVdZ5y5lJWVro4vBwgKkm7kKbtvs=; b=eYLXz5EK4OaW2XS1W/sfDyzjTUA0SkJoroi2mpqOZMtHOsUJfKaml6Zo0BpNgz7U04 /gFWboNVfiiNmHPQutc8H7FYkWO0Q9JdDfsoEaPnEwiCif+hOYKvLvCGpH6VrxUpi8nJ EaRzZW/MBNSknkmomJWDel0kFUCf4gXXTWx5B9cq5qFsGOp1AarNAVyn73cfQJM1LljR yuuQbVYuXgPn81O2KrIZR4kKgdU0Dl1606vGilFjPcUTKGG9r0rzmS+sD9WJt3VRH8WZ qzcrxofAVGgUZszE3yC1eOHVHsgN2UOAE6gQvNQ/EEKeSU+lBdKQsSETeX0F2Mz5MiJF QDQg== X-Gm-Message-State: AOAM533rIUKsucVjA7p73zBgam6Km4m3Wud67uJwNJDOu0qAr3coXw2G R5xPvFstOHXa6MMvmsC8bRDf2vs+5gSvuuiE54o= X-Google-Smtp-Source: ABdhPJxKjERpmeOqvoL0NrvdDKFUHDmaV7mJifKlIHnp2LwPeGJjeT+LFnPJZt8i3aUF8tEAO8RWAeA4lt/IMgDbLZ4= X-Received: by 2002:a6b:8f50:: with SMTP id r77mr7763300iod.141.1605531216915; Mon, 16 Nov 2020 04:53:36 -0800 (PST) MIME-Version: 1.0 References: <7f06d460-a4bb-652a-bba0-fe5fe5e6478f@free.fr> In-Reply-To: From: Fabien Imbault Date: Mon, 16 Nov 2020 13:53:25 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000dc31ad05b438ddf8" Archived-At: Subject: Re: [GNAP] Quick review of draft-ietf-gnap-core-protocol-00 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: Mon, 16 Nov 2020 12:53:43 -0000 --000000000000dc31ad05b438ddf8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, I've been thinking more about your feedback. Marked with [FI] in your initial comments. We probably need to address your feedback early on, and make sure the WG is fine with those. Overall I believe we can achieve much of what you'd want regarding privacy, without impacting too much the architecture. Fabien On Wed, Oct 21, 2020 at 7:20 PM Fabien Imbault wrote: > Hi Denis, > > The "many options" is only a temporary state, the goal was to expose the > decisions that need to be made to the mailing list. We can quickly reduce > to a manageable level by having focused discussions. > > As for the remainder of your comments, the only item we considered so far > was one of principle: that privacy is an important goal of the work. The > rest of the focus was on taking the best out of XYZ and XAuth. So > incorporating the discussions that occurred just before the focus group > wasn't a goal. You can already see that with regards to terminology, wher= e > insightful discussions occurred but the paint was really very fresh. > > I find what you explain really interesting. It will need to be analyzed i= n > detail. The caveat is that we have less background experience of what it > means in practice (compared to the current document vs OAuth2). I guess i= t > will require a bit of experimentation, to avoid corner cases. > > More specific comments/questions coming later :-) > > Fabien > > > Le mer. 21 oct. 2020 =C3=A0 17:58, Denis a =C3=A9cri= t : > >> Hi, >> >> I haven't read all the document in details, but I have browsed through >> it: this took me about 3 hours. >> As it is, I don't consider that the current text (more than 100 pages !) >> is a "good starting point". >> >> The less that I can say is that the document is far from being crystal >> clear, is too complex and includes so many options >> (without indicating which parameters are required and which ones are >> optional) that it will be impossible to claim that >> an implementation complies with it. >> >> In addition, it is unfortunate that many of the discussions we have had >> on the mailing list have not been incorporated by the design team. >> >> Here are some comments: >> >> 1. An overview is missing since the various features are only being >> discovered while reading the document. >> >> 2. A key question that might interest a reader is the following: what >> are the common points and the main differences with OAuth ? >> >> 3. The whole document is "AS centric" while it should also be "RS >> centric". These two concepts have been explained on the mailing list. >> > [FI] indeed it is centered around the AS. What's your proposition if we were to change the text? Notice that most business scenarios today require an AS centric approach. We've seen from previous discussion that it doesn't preclude from enabling more privacy. > >> 4. The document only speaks about "*the* AS", as if only one AS would >> exist which is obviously not the case. >> The first access made to a RS shall be able to identify which ASs ar= e >> trusted by the RS. In addition, for each trusted AS, the RS should be ab= le >> to indicate which access rights are needed to perform every operatio= n >> possible at that stage. For any subsequent stage, the RS may also indica= te >> which attributes or access rights are needed to perform each >> subsequent operation. >> > [FI] There's also two related questions : a) do we allow multiple-AS scenarios? b) do we allow other AS deployment options, and if so, how? (like a personal AS on your phone). > >> 5. "API=E2=80=99s documentation" versus "API discovery". Whereas the API= =E2=80=99s >> documentation is static and not necessarily up to date or the RC softwar= e >> is not necessarily up to date, API discovery provides real time >> information which is necessarily up to date. >> >> There should be an API discovery mechanism for RSs. >> > [FI] is that our job to do that? There are already existing discovery mechanisms in the wild that people could use. > >> Using an appropriate HTTP OPTIONS request, the RC should be able to >> query the RS in order to know *at any point of time*: >> >> >> - the operations that can be done (i.e. which methods are available >> on which data objects), and >> - the access control characteristics associated with each of these >> operations (i.e. which ASs are being trusted by the RS >> and what should be the incorporated into access token(s) in terms of >> attributes types (and optionally attribute values) >> or in terms of capabilities (i.e. permissions granted). >> >> 6. The "user consent" phase has been ignored. It should be done at the >> RS. Using information obtained from a RS, a RC should be able >> to select which AS it wants to contact and explicitly agree to >> request the mentioned attributes to that AS. Alternatively, when the use= r >> consent phase >> is not done at the RS, it shall be done at the AS. >> > [FI] To be discussed further. I believe an optional separate Interaction Server solves this case, without disruption for standard use cases (OAuth2 like) that are likely to remain. > >> 7. The content and the format of access tokens shall not be considered >> to be opaque to the RC so that the RC can inspect it. >> This is a matter of confidence to make sure for the RC (and for the >> user) that no "extra" information has been included by the AS into the >> access token. >> > [FI] This might go a bit further than the GNAP's mandate (especially if i= t becomes a mandatory requirement). But supposing we support non-opaque tokens, does it preclude supporting opaque tokens? It's just a different trust model, which makes sense if people agree with your premises (previous items), but that are less relevant if people still consider the AS as the central piece. Also one great thing with opaque tokens is that it makes the system easier to upgrade (you don't really care about what a token is). One alternative way would be to allow RS call to AS for verification (including revocation status) and include a checksum. > >> 8. "Resource Owner (RO) : Authorizes the request from the RC to the RS", >> full stop. The RO is associated with a RS, not with an AS. >> The RS can know in advance with attributes or access rights are >> needed to grant a given operation. >> > [FI] ideally makes sense I think, but need to check the practical implications. Related to terminology #6. > >> 9. The model should allow the use of both Access Control Lists and of >> Capabilities Lists. >> >> >> - Access control lists contain identifiers of users and/or >> identifiers of users groups or identity claims in relationship with a= n >> operation. >> - Capabilities lists contains operations granted on services within a >> RC. >> >> As a consequence, access tokens may contain identifiers of users >> and/or identity claims and/or identifiers of users groups and/or >> capabilities. >> Whereas identifiers of users and/or identifiers of users groups >> and/or identity claims may be managed by an AS independently from RSs, >> this is not the case for capabilities where a RO associated with a R= S >> needs to interact with the AS either in advance or in real time >> (which makes such mechanism much more complex). >> > [FI] We had several discussions on this topic, and I still consider the current approach to be the right path. I don't think your scenario is really more complex, that's basically what people are doing when using a policy engine (which can be as simple as casbin.org for instance) to generate access tokens. More fundamentally, ensuring least privilege using ACLs is known to be a hard problem. > >> 10. In the case where access control lists are being used, there should >> be a possibility for a RC, for privacy reasons, to hide the identifier >> of the RS to the AS (usually a URL) when requesting an access token= . >> A method able to support such feature has been discussed extensively on = the >> mailing list. >> > [FI] depends on decision regarding previous item. > >> 11. The text states: "Authorization Server (AS) Manages the requested >> delegations for the RO". This is only one of two possibilities. >> The interaction between a RO and an AS should be considered as an >> option. If a RO needs to interact, for privacy reasons, it should >> preferably >> interact with the RS only. >> > [FI] The problem with working at the RS level is that it makes the integration harder (we don't exactly know what people will implement). As a consequence, I would be in favor of an optional separation of that issue in an Interact Server, which could be distinct from the AS to alleviate privacy concerns. > >> 12. The text states: "Resource A protected API served by the RS and >> accessed by the RC. Access to this resource is delegated by the RO as pa= rt >> of the grant process". >> The second part of the sentence should be deleted since a RO is no= t >> necessarily involved in the grant process. >> > [FI] Yes, more generally we should check that we can deal with user =3D = RO (usually considered as the default case) and user !=3D RO (not often carefully designed). I think the text already goes into much more details than OAuth2 for this (cf sequences 1.4). > >> 13. The text states: "Resource Client (RC, aka "client") Requests >> tokens from the AS and uses tokens at the RS. >> An instance of the RC software is identified by its key, which can >> be known to the AS prior to the first request". >> >> This is confusing. The key does not necessarily identify an >> instance of the RC software. >> An instance of the RC software uses a binding key which (for >> privacy reasons) should be dynamic but which may alternatively be static= . >> > [FI] The client instance solves those issues. Might need to update the wa= y it is described in the text. > >> 14. For privacy reasons, calls from an RS to an AS, such as token >> introspection, should be avoided. >> > [FI] Token introspection (as well as other aspects related to token management) should be reviewed in depth, currently we don't solve many of the problems we see in the OAuth world. I don't believe calls from an RS to an AS should be avoided though, on the contrary there might be an alternative to your proposal where the RS could use a public AS endpoint for the revocation list. > >> 15. Section 2 deals with the parameters when making calls from a RC to >> an AS. This section would need to be revisited. >> Hereafter are only some (of many) concerns about the current text. >> The most important is to identify which parameters shall be used >> and may be used when making a call to get an access token. >> >> The text states: "resources Describes the rights that the RC is >> requesting for one or more access tokens to be used at RS=E2=80=99s. >> Section 2.1". Then after: "Each object contains a "type" property >> that determines the type of API that the RC is calling. >> (...) The value of this field is under the control of the AS. >> > [FI] please provide your input to the terminology work. > >> The value of this field should not be under the control of the AS >> but of the RS. >> > [FI] ultimately, the field needs to correspond to what the RS provides, even if the AS is the one that generates the access token. Your proposal is interesting but that would put more effort on the RS side, with impacts on deployability. > >> The text states: "actions The types of actions the RC will take at >> the RS". This is needed when capabilities are being used but not needed >> for the other cases. Revealing actions to an AS is against the >> user's privacy. >> > [FI] technically this could be any alias defined by the RS. Remember we discussed RS hiding strategies (ex: concealed identifier) which solve that issue. > >> The text states: "locations The location of the RS as an array of >> strings. These strings are typically URIs identifying the location of th= e >> RS." >> > >> It is typically URLs (not URIs) but it may also be *service names* >> so that an access token can be delegated by a first RS to a second RS >> belonging to the same service without the need for the first RS to >> request another access token. >> > [FI] delegation from a RS to another is a topic in itself, yet to be explored. I remember you sent various inputs on that, we might need to review them in detail. > >> Denis >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000dc31ad05b438ddf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0

I'= ve been thinking more about=C2=A0your=C2=A0feedback. Marked with [FI] in yo= ur initial comments.

We probably need to address y= our feedback early on, and make sure the WG is fine with those. Overall I b= elieve we can achieve much of what you'd want regarding privacy, withou= t impacting too much the architecture.=C2=A0

Fabie= n=C2=A0



On Wed, Oct 21, 2020 at 7:20 PM = Fabien Imbault <fabien.imbau= lt@gmail.com> wrote:
Hi Denis,
=
The "many options" is only a temporar= y state, the goal was to expose the decisions that need to be made to the m= ailing list. We can quickly reduce to a manageable level by having focused = discussions.

As for the = remainder of your comments, the only item we considered so far was one of p= rinciple: that privacy is an important goal of the work. The rest of the fo= cus was on taking the best out of XYZ and XAuth. So incorporating the discu= ssions that occurred just before the focus group wasn't a goal. You can= already see that with regards to terminology, where insightful discussions= occurred but the paint was really very fresh.=C2=A0

I find what you explain really interesting. It= will need to be analyzed in detail. The caveat is that we have less backgr= ound experience of what it means in practice (compared to the current docum= ent vs OAuth2). I guess it will require a bit of experimentation, to avoid = corner cases.

More speci= fic comments/questions coming later :-)=C2=A0

Fabien=C2=A0

<= br>
Le mer. 21 oct. 2020 =C3=A0 17:58, Denis <denis.ietf@free.fr&g= t; a =C3=A9crit=C2=A0:
=20 =20 =20

Hi,

I haven't read all the document in details, but I have browsed through it: this took me about 3 hours.
As it is, I don't consider that the current text (more than 100 pages !) is a "good starting point".

The less that I can say is that the document is far from being crystal clear, is too complex and includes so many options
(without indicating which parameters are required and which ones are optional) that it will be impossible to claim that
an implementation complies with it.

In addition, it is unfortunate that many of the discussions we have had on the mailing list have not been incorporated by the design team.

Here are some comments:

1. An overview is missing since the various features are only being discovered while reading the document.

2. A key question that might interest a reader is the following: what are the common points and the main differences with OAuth ?

3. The whole document is "AS centric" while it should also b= e "RS centric". These two concepts have been explained on the mailing list.

[= FI] indeed it is centered around the AS. What's your proposition if we = were to change the text?
Notice th= at most business scenarios today require an AS centric approach. We've = seen from previous discussion that it doesn't preclude from enabling mo= re privacy.
<= div dir=3D"auto">


4. The document only speaks about "the AS", as if only one AS would exist whic= h is obviously not the case.
=C2=A0=C2=A0=C2=A0 The first access made to a RS shall be able to i= dentify which ASs are trusted by the RS. In addition, for each trusted AS, the RS should be able
=C2=A0=C2=A0=C2=A0 to indicate which access rights are needed to perform every operation possible at that stage. For any subsequent stage, the RS may also indicate
=C2=A0 =C2=A0 which attributes or access rights are needed to perform each subsequent operation.

[FI]=C2=A0There's also two related quest= ions : a) do we allow multiple-AS scenarios? b) do we allow other AS deploy= ment options, and if so, how? (like a personal AS on your phone).=C2=A0


5. "API=E2=80=99s documentation" versus "API discovery". Whereas the API=E2=80=99s documen= tation is static and not necessarily up to date or the RC software
=C2=A0=C2=A0=C2=A0 is not necessarily up to date, API discovery pro= vides real time information which is necessarily up to date.

=C2=A0=C2=A0=C2=A0 There should be an API discovery mechanism for RSs.

[FI] is that our job to do that? There a= re already existing discovery mechanisms in the wild that people could use.= =C2=A0


=C2=A0=C2=A0=C2=A0 Using an appropriate HTTP OPTIONS request, the R= C should be able to query the RS in order to know at any point of time:

  • the operations that can be done (i.e. which methods are available on which data objects), and
  • the access control characteristics associated with each of these operations (i.e. which ASs are being trusted by the RS
    and what should be the incorporated into access token(s) in terms of attributes types (and optionally attribute values)
    or in terms of capabilities (i.e. permissions granted).    <= /li>

6. The "user consent" phase has been ignored. It should be done at the RS. Using information obtained from a RS, a RC should be able
=C2=A0 =C2=A0 to select which AS it wants to contact and explicitly agree to request the mentioned attributes to that AS. Alternatively, when the user consent phase
=C2=A0 =C2=A0 is not done at the RS, it shall be done at the AS.

[FI] To be discussed further. I believe an optional separate Inte= raction Server solves this case, without disruption for standard use cases = (OAuth2 like) that are likely to remain.


7. The content and the format of access tokens shall not be considered to be opaque to the RC so that the RC can inspect it.
=C2=A0=C2=A0=C2=A0 This is a matter of confidence to make sure for = the RC (and for the user) that no "extra" information has been included b= y the AS into the access token.

[FI] This might go a bit further= than the GNAP's=C2=A0mandate (especially if it becomes a mandatory req= uirement). But supposing we support non-opaque tokens, does it preclude sup= porting opaque tokens? It's just a different trust model, which makes s= ense if people agree with your premises (previous items), but that are less= relevant if people still consider the AS as the central piece.=C2=A0=C2=A0=
Also one great thing with opaque = tokens is that it makes the system easier to upgrade (you don't really = care about what a token is).=C2=A0

One alternative way would be= to allow RS call to AS for verification (including revocation status) and = include a checksum.=C2=A0

<= span style=3D"font-family:Arial" lang=3D"EN-US">
8. "Resource Owner (RO) : Authorizes the request from the RC to the RS", full stop. The = RO is associated with a RS, not with an AS.
=C2=A0=C2=A0=C2=A0 The RS can know in advance with attributes or access rights are needed to grant a given operation.

[FI] ideally makes sense I think,=C2=A0but = need to check the=C2=A0practical implications. Related to terminology #6.= =C2=A0=C2=A0
=


9. The model should allow the use of both Access Control Lists and of Capabilities Lists.

  • Access control lists contain identifiers of users and/or identifiers of users groups or identity claims in relationship with an operation.
  • Capabilities lists contains operations granted on services within a RC.

=C2=A0=C2=A0=C2=A0=C2=A0 As a consequence, access tokens may contain identifiers of users and/or identity claims and/or identifiers of users groups and/or capabilities.
=C2=A0=C2=A0=C2=A0 Whereas identifiers of users and/or identifiers of users groups and/or identity claims may be managed by an AS independently from RSs,
=C2=A0=C2=A0=C2=A0 this is not the case for capabilities where a RO associated with a RS needs to interact with the AS either in advance or in real time
=C2=A0=C2=A0=C2=A0 (which makes such mechanism much more complex). =


<= div>[FI] We had several discussions on this topic,= =C2=A0and I still consider the current approach to be the right path. I don= 't think your scenario is really more complex, that's basically wha= t people are doing when using a policy engine (which can be as simple as casbin.org for instance) to generate access= tokens.=C2=A0
More fundamentally,= ensuring least privilege using ACLs is known to be a hard problem.<= /div>


10. In the case where access control lists are being used, there should be a possibility for a RC, for privacy reasons, to hide the identifier
=C2=A0=C2=A0=C2=A0=C2=A0 of the RS to the AS (usually a URL) when requesting an access token. A method able to support such feature has been discussed extensively on the mailing list.

<= /div>
[FI] depends on decisi= on regarding previous item.=C2=A0=C2=A0


11. The text states: "Authorization Server (AS)=C2=A0 Manages the requested delegations for the RO". This is only one of two possibilities.
=C2=A0=C2=A0=C2=A0=C2=A0 The interaction between a RO and an AS sho= uld be considered as an option. If a RO needs to interact, for privacy reasons, it should preferably
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interact with the RS only.

[FI] The problem with working at the RS level is that it makes the integ= ration harder (we don't exactly know what people will implement). As a = consequence, I would be in favor of an optional separation of that issue in= an Interact Server, which could be distinct from the AS to alleviate priva= cy concerns.
=


12. The text states: "Resource=C2=A0 A protected API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process".
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The second part of the sentence should be deleted since a RO is not necessarily involved in the grant process.

[FI]=C2=A0=C2=A0<= font color=3D"#ff0000">Yes, more generally we should check that we can deal= with user =3D RO (usually considered as the default case) and user !=3D RO= (not often carefully designed). I think the text already goes into much mo= re details than OAuth2 for this (cf sequences 1.4).=C2=A0=C2=A0


13. The text states: "Resource Client (RC, aka "client")=C2=A0 Requests tokens from the AS and uses tokens at the RS.=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An instance of the RC software is id= entified by its key, which can be known to the AS prior to the first request".

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is confusing. The key does not necessarily identify an instance of the RC software.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An instance of the RC software uses = a binding key which (for privacy reasons) should be dynamic but which may alternatively be static.

[FI] The client instance solves those issu= es.=C2=A0Might need to update the way it is described in the text.


14. For privacy reasons, calls from an RS to an AS, such as token introspection, should be avoided.

[FI] Token intr= ospection (as well as other aspects related to token management) should be = reviewed in depth, currently we don't solve many of the problems we=C2= =A0see in the OAuth world. I don't believe calls from an RS to an AS sh= ould be avoided though, on the contrary there might be an alternative to yo= ur proposal where the RS could use a public AS endpoint for the revocation = list.=C2=A0
<= div dir=3D"auto">


15. Section 2 deals with the parameters when making calls from a RC to an AS. This section would need to be revisited.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hereafter are only some (of many) co= ncerns about the current text. The most important is to identify which parameters shall be used
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and may be used when making a call to get an access token.

=C2=A0=C2=A0=C2=A0=C2=A0 The text states: "resour= ces=C2=A0 Describes the rights that the RC is requesting for one or more access tokens to be used at RS=E2=80=99s= .
=C2=A0=C2=A0=C2=A0=C2=A0 Section 2.1". Then after: "Each object contains a "type" property = that determines the type of API that the RC is calling.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (...)=C2=A0 The value of this field is under the control of the AS.

[FI] please provide your input to the terminology work.=C2=A0<= /div>


=C2=A0=C2=A0=C2=A0=C2=A0 The value of this field should not be under the control of the AS but of the RS.

= [FI] ultimately, the field needs to correspond to w= hat the RS provides, even if the AS is the one that generates the access to= ken.=C2=A0
Your proposal is intere= sting but that would put more effort on the RS side, with impacts on deploy= ability.=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0 The text states: "actions=C2=A0 The types of actions the RC will take at the RS". This is needed when capabilities are being used but not needed
=C2=A0=C2=A0=C2=A0=C2=A0 for the other cases. Revealing actions to an AS is against the user's privacy.

<= /div>
[FI= ] technically this could be any alias defined by the RS. Remember we discus= sed RS hiding strategies (ex: concealed identifier) which solve that issue.= =C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0 The text states: "locations=C2= =A0 The location of the RS as an array of strings. These strings are typically URIs identifying the location of the RS."=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0 It is typically URLs (not URIs) but it may also be service names so that an access token can be delegated by a first RS to a second RS
=C2=A0=C2=A0=C2=A0=C2=A0 belonging to the same service without the need for the first RS to request another access token.

--000000000000dc31ad05b438ddf8-- From nobody Mon Nov 16 08:36: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 351BD3A139B for ; Mon, 16 Nov 2020 08:35:55 -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=neutral reason="invalid (public key: not available)" 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 GzrarVxzGrnM for ; Mon, 16 Nov 2020 08:35:53 -0800 (PST) Received: from DEU01-FR2-obe.outbound.protection.outlook.com (mail-fr2deu01on2071d.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e24::71d]) (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 2EDD63A12CD for ; Mon, 16 Nov 2020 08:35:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NIDQHofLy8zlOjmbRz1/StZgoewJnRsLSKqdvnNOpm7F8Ej387BeGbMy70uRWgY29PZXwFwts9M7NS78RMf4VdQ7GRvnxnLr6JSc29cq2CRBVo5yq0+Oshmpnc+aU6/xNNlnHka7h1fM86t5FuXL57VxN7fTvwb7jLCkAG6gTBoe2qDfqw+wb9HUy+Q3JqYCEuKQWxCZBp67FKPYcQPW+CWKpx8yKyXZn+kn/Wmr2xOLBBZYSVN2PNFxrYEn2FDHBdUJ9nGBdMymYYTKn0enESlyRn41+G4cX1O16J5xaTIySpk7chu3m3YmT2ZhgRylktdeaxMfi3BEfJ7glJi6uw== 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=2zuAxzCGXcWY3QuqsEADSdHjD00r9efzwuC1gRiSwL0=; b=BzzEY8aoyoDO3eS4+xqAEEJs24bdj6gF6LspPYX/1tdG1Mn8+igL0l4zLWNqzNbMaSbs58i6heUhmMLH45NYzrh/74TFrqSpqF8G7FSI/Zy5dVnvlM4eqZtvZ34rpR4UPrT0HPID6rno9swzMFKwbAc93zuoU5GXjOfCegi1wzPIan86FFFWtmAs3X9NRBaKjJ08OFnAQYZi8X84nM8Mg6xbrad4HEiPeYqlF5xFesS0pfuGlGk4/gZ+z9Nk04OfPQKyT7RIlANg86O618QZqd2yuStxLvjhkPzOHGvr0felMcR1FHaWfev+FcJd+Wlm7+BD2Rrzd8diOJ189N+LcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=adorsys.de; dmarc=pass action=none header.from=adorsys.de; dkim=pass header.d=adorsys.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2zuAxzCGXcWY3QuqsEADSdHjD00r9efzwuC1gRiSwL0=; b=9Y5D43yfSKjM8FPCU/PvxyifHuMzjUuWiVwodeoY/AWXJ5lfRha1OTiT72/3KjJTg1ciBekwAJTTAj/De1KnA/gWCe1KaK22zmM7n39YYQe9bTvR6/O42y732li6exPGeKIEheBktaZtH8M3j1KCi9I+5sm9MhnN5b56EDQTO+grvCQRD7Uup3YTGZAq2B0zkHyLPpJh6UV3g+an7OM0JLZhFVxHfVGwh6YC129aRJVuAZUFLzvzsc/jSNm706/ImsyBBFO29jKW/ogqtcsv0cqJAbSrzQKL4zuzcpyOXUK4evehUvdCkgVIGbkssq2zqmjM2DFukkqd6Me2XHr4yw== Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:11::11) by FR2P281MB0059.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.15; Mon, 16 Nov 2020 16:35:42 +0000 Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::b06b:117e:61f0:138b]) by FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::b06b:117e:61f0:138b%3]) with mapi id 15.20.3589.017; Mon, 16 Nov 2020 16:35:42 +0000 From: Francis Pouatcha To: Fabien Imbault , Francis Pouatcha CC: GNAP Mailing List Thread-Topic: [GNAP] Review of draft-ietf-gnap-core-protocol-00 Thread-Index: AQHWsiy3H8is1hHc2keFJtXpCHRvoKnGFMOAgATzTCY= Date: Mon, 16 Nov 2020 16:35:42 +0000 Message-ID: References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=adorsys.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [65.33.157.159] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5b060a20-3038-4aa1-1734-08d88a4da8e7 x-ms-traffictypediagnostic: FR2P281MB0059: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B0aQtFopH5aTo33UxzDaIPCRbJMNjf6lYxbMwlkdbj69fIXew0y6b3H+Q4cchzDpj5YeFUjuVtbTIun39tAMXW0hJmRzAOHoCP90xFpBeTmC2QAC+QxiFz9IjAyaCwCmkf5KN9vLywUVIPfXvn/0LrdeTXjK2zG6NoDPTeZ1ms2XZrAcsTbQn/LwuCHv2JYqZuoNFUlHIYtvtThRktzaPOS4H7XNUx+iVR6f72sMJQ1XNnAQeA4NiwxbOudXuMDRciZyOK642Vt6zu/TeBVdADxfxgUVtt2ojV8d/pwoG2EQE70O0vhW3eV+kM9ehG9gawyvPlFrpD9IPWKZ/7Dsk/pSqIOqG1pA/6MVcKTzPmCrOiQzwqAbiwDBb92O8ik0wxJxsT8CXYaayFSCYrVzoQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(366004)(136003)(346002)(39840400004)(110136005)(9686003)(7696005)(186003)(86362001)(6506007)(53546011)(26005)(4326008)(478600001)(33656002)(19627405001)(55016002)(8936002)(2906002)(316002)(66946007)(66556008)(8676002)(166002)(66574015)(83380400001)(52536014)(71200400001)(5660300002)(64756008)(66446008)(66476007)(76116006)(91956017); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: jl0RzYA8khyPit7bnixbylgFN/+xvQhM8+VHQSdOaKT7zEfk1NrFyuW0DJI4tpflb0kOQEcI6IMvl8YjmQ5zSeOz1U4NytjhPuNuhs/NuUTCNYWI7oT6Ho4C9iD1FLkk7qSfJ/95+q9FKKdYanr51a0Yu0aq2jPPaFDg0Xg1gJPwDcR++3BKnakcIXjRFNYg2jlnilKBEHuPGtjuq9xEbwFlvvU4lfV1vn0x12d4h/EADyH/01KCt+olGmxwAMTkU8lbsx7ayPXK0zSOamDKIBPVGuWsVI4ywVir9yOR/l8EC6KP5T1aYZiCvv6FkhCEhFhZ8UixO3bh1iAfCBrwkdrbH4DmvGh3NIw2EFndWfzejqbOv0ByOWpt/DJyexxc0lblORsChzZmFSQOj1cAO5Pai5jbLC239Olm1FvGJCJIeYq/pCxtLGAfvyJOY3L2M6LjJ+er4DvOpcJAkEoAuPsRPniwpGY6Wky2/DCCKsxHYcykNTPmoMoG9yWxbV9G1uxxAx41zF9BOkqRsWSEaF1Yb1xo/s5kgkau+Pp02NWC+dt7oZ3FDeyHAKa8jyfTJGNVtgDwZ+SRJR3IdUDcNCQfysoLkx30981TJ8Tp9don7ixeeBW8IUVsbUhMEtwLvVL1N6BJfo/RIgyUNzNxISwGrMkafiiAcKOPOKbcju7BvR/wOdeNpdaog8wnMcX/cC9TwbkqxaZf8fRypbiwduWkjPlsf62dGjnNGq9PQgqp85GVo/sHBLCTpb3bYrP/P6OyFLq2f1dhoBcnlft68w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FR2P281MB0106C83420ED3F8DF2723BFD8DE30FR2P281MB0106DEUP_" MIME-Version: 1.0 X-OriginatorOrg: adorsys.de X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 5b060a20-3038-4aa1-1734-08d88a4da8e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2020 16:35:42.2701 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5e2c5484-e522-479d-91ca-515d6e0ce228 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rj18TjeYMagMJWR4h8m/viBdvIjvC61tsRXvOFCgduReLyY05rnGR3FKQkX1Db8Tcsixjj1fUFYnjmz2nwp0ISOqJLySt2AkqVsaGQzmkhs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0059 Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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: Mon, 16 Nov 2020 16:35:59 -0000 --_000_FR2P281MB0106C83420ED3F8DF2723BFD8DE30FR2P281MB0106DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gVHVlLCBOb3YgMywgMjAyMCBhdCAxMTowMCBQTSBGcmFuY2lzIFBvdWF0Y2hhIDxmcG89NDBh ZG9yc3lzLmRlQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFkb3JzeXMuZGVAZG1hcmMuaWV0Zi5v cmc+PiB3cm90ZToNCg0KQikgQ3VycmVudCBEb2N1bWVudA0KDQpSb2xlcyBkZXNjcmlwdGlvbiBz aGFsbCBub3QgaG9sZCBhbnkgYXNzdW1wdGlvbiBvbiB0aGUgcGh5c2ljYWwgc3RydWN0dXJlIG9m IHRoZSBwYXJ0eSBmdWxmaWxsaW5nIHRoZSByb2xlcy4NCltGSV0gbm90IHN1cmUgd2hhdCB5b3Ug bWVhbg0KIFtGUF0gZm9yIGV4YW1wbGUsIHdlIGFzc3VtZSB0aGUgQVMgaXMgYSBzZXJ2ZXIhIElu IG1vc3QgU1NJIGJhc2VkIHVzZSBjYXNlcywgdGhlIEFTIHdpbGwgYmUgcnVubmluZyBvbiB0aGUg dXNlciBkZXZpY2UuIFNlZSBTSU9QIChodHRwczovL2lkZW50aXR5LmZvdW5kYXRpb24vZGlkLXNp b3AvKS4NCg0KUm9sZXM6DQotPiBncmFudCBlbmRwb2ludCBvZiB0aGUgQVM6IFdoeSBpcyB0aGlz IGEgcG9zdCByZXF1ZXN0PyBUaGlzIGVsaW1pbmF0ZXMgdGhlIGNoYW5jZSBvZiBoYXZpbmcgdXNl ciBkZXZpY2UgaG9zdGVkIEFTIChubyBzZXJ2ZXIpLg0KW0ZJXSB3aGF0IHdvdWxkIHlvdSBwcm9w b3NlIGluc3RlYWQ/DQpXb3VsZCBhbHNvIGJlIGludGVyZXN0ZWQgdG8gdW5kZXJzdGFuZCBiZXR0 ZXIgdGhlIGRlcGxveW1lbnQgbW9kZWwgd2hlbiB0aGVyZSBpcyBubyBzZXJ2ZXIuIFRoYXQncyBz b21ldGhpbmcgdGhhdCB3YXMgZGlzY3Vzc2VkIHNldmVyYWwgdGltZXMgYnV0IEknbSBzdGlsbCBt aXNzaW5nIHRoZSB1bmRlcmx5aW5nIGFyY2hpdGVjdHVyZSBhbmQgdXNlIGNhc2UuDQogW0ZQXSBT ZWUgYWJvdmUgKFNJT1ApLiBUaGVyZSB3aWxsIGJlIGEgbG90IG9mIGlkZW50aXR5IHdhbGxldHMg b3BlcmF0ZWQgb24gZW5kIHVzZXIgZGV2aWNlLg0KDQotPiBSZXNvdXJjZSBPd25lciAoUk8pIDog QXV0aG9yaXplcyB0aGUgcmVxdWVzdD8gRG9lcyBpdCBhdXRob3JpemUgdGhlIHJlcXVlc3Qgb3Ig dGhlIGFjY2VzcyB0byBhIHJlc291cmNlPw0KW0ZJXSB5ZXMsIHdlIHNob3VsZCBtYWtlIHRoZSB3 b3JkaW5nIGNsZWFyZXINCg0KTWlzc2luZyBTZWN0aW9uIEludGVyYWN0aW9uczoNCi0tPiBUaGlz IHNlY3Rpb24gc2hhbGwgaW50cm9kdWNlIHRoZSBub3Rpb24gb2YgaW50ZXJhY3Rpb24gYmVmb3Jl IHdlIHN0YXJ0IGxpc3RpbmcgaW50ZXJhY3Rpb24gdHlwZXMuDQpbRkldIHllcw0KDQpJbnRlcmFj dGlvbiBUeXBlczoNCi0tPiBJIHByZWZlciBhIGNsYXNzaWZpY2F0aW9uIHdpdGggUmVkaXJlY3Qs IERlY291cGxlZCBhbmQgRW1iZWRkZWQgaXMuIEluIHRoZSBkcmFmdCwgd2UgaGF2ZSBvbmUgcmVk aXJlY3QgYW5kIDIgZGVjb3VwbGUgaW50ZXJhY3Rpb25zIGFuZCBub3RoaW5nIGVsc2UuDQpbRkld IHRoaXMgc2hvdWxkIGJlIGhhbmRsZWQgYXMgYSBzcGVjaWZpYyBkaXNjdXNzaW9uIGl0ZW0uIEFz IGEgcmVtaW5kZXIsIGhvdyB3b3VsZCB5b3UgZGVmaW5lIGVtYmVkZGVkPw0KDQpJbiBwcmFjdGlj ZSB0aGVyZSdzIGF0IGxlYXN0IHRoZXNlIG1vZGVzOg0KLSByZWRpcmVjdCBhbmQgcmVkaXJlY3Qg YmFjaw0KLSByZWRpcmVjdCB0byBkaWZmZXJlbnQgYnJvd3NlciBvciBkZXZpY2UNCi0gdXNlciBj b2RlDQotIENJQkENCltGUF0gVGhpcyBjbGFzc2lmaWNhdGlvbiBpcyBsaW1pdGVkLg0KDQogICog ICBSZWRpcmVjdDogc2FtZSBkZXZpY2UsIHNhbWUgb3IgZGlmZmVyZW50IHVzZXIgYWdlbnRzIChi cm93c2VyLCBtb2JpbGUgYXBwLCBkZXNrdG9wIGFwcCwgLi4uKQ0KICAqICAgRGVjb3VwbGVkOiBk aWZmZXJlbnQgZGV2aWNlcw0KICAqICAgRW1iZWRkZWQgOiBSQyBjYXJyaWVzIFJPIGF1dGhvcml6 YXRpb24gdG8gQVMNCg0KDQpSZXNvdXJjZSBBY2Nlc3MgUmVxdWVzdCB2cy4gUmVzb3VyY2UgUmVx dWVzdA0KLS0+IEJvdGggYXJlIG1peGVkIHVwLiBObyBjbGFyaWZpY2F0aW9uIG9mIHRoZSBjb250 ZXh0IG9mIGVhY2ggc2VjdGlvbi4NCltGSV0gY291bGQgeW91IGNsYXJpZnkgd2hhdCB5b3UnZCBl eHBlY3QuICBCdHcgb24gdGhpcyB0b3BpYywgdGhlcmUncyBhIG1vcmUgZ2VuZXJhbCBkaXNjdXNz aW9uIG9uIHdoZXRoZXIgd2Ugc2hvdWxkIG1ha2UgYSBkaXN0aW5jdGlvbiBvciBub3QuDQrigItb RlBdOiBIZXJlOg0KDQogICogICBSZXNvdXJjZSBBY2Nlc3MgUmVxdWVzdDogUmVxdWVzdGluZyBB Y2Nlc3MgdG8gYSByZXNvdXJjZS4gUmVzcG9uc2UgaXMgYW4gYWNjZXNzIHRva2VuIChvciBhbnkg dHlwZSBvZiBncmFudCkNCiAgKiAgIFJlc291cmNlIFJlcXVlc3Q6IFJlcXVlc3QgdGhlIHJlc291 cmNlLiBSZXNwb25zZSBpcyB0aGUgcmVzb3VyY2UgKG9yIGEgY29ycmVzcG9uZGluZyBleGVjdXRp b24pDQoNClRva2VuIENvbnRlbnQgTmVnb3RpYXRpb24NCi0tPiBOb3QgZXhwcmVzc2VkIGFzIHN1 Y2guIFRoaXMgaXMgY2VudHJhbCB0byBHTkFQIGFuZCBub3QgcmVwcmVzZW50ZWQgZW5vdWdoICBp biB0aGUgZG9jdW1lbnQuDQpbRkldIHJpZ2h0LiBUaGlzIHNob3VsZCBiZSBhIHNwZWNpZmljIGRp c2N1c3Npb24gaXRlbS4NCg0KUmVxdWVzdGluZyAiVXNlciIgSW5mb3JtYXRpb24NCndlIGlkZW50 aWZ5IHR3byB0eXBlcyBvZiB1c2VyczogUlEgYW5kIFJPLiBJdCB3aWxsIGJlIGJldHRlciBub3Qg dG8gcmVmZXIgdG8gYSB1c2VyIGluIHRoaXMgZHJhZnQsIGJ1dCBlaXRoZXIgdG8gYSBSUSBvciBh biBSTy4NCltGSV0geWVzIHRoYXQgd291bGQgYXZvaWQgcG90ZW50aWFsIG1pc3VuZGVyc3RhbmRp bmdzLiBBbHRob3VnaCBpbiB0aGUgZW5kLCBwZW9wbGUgd2lsbCB0cmFuc2xhdGUgUlEgaW50byB1 c2VyIG9yIGVuZC11c2VyIG1vc3Qgb2YgdGhlIHRpbWUuIENmIGluIGRlZmluaXRpb24sIGN1cnJl bnRseSB3ZSBoYXZlIFJlcXVlc3RpbmcgUGFydHkgKFJRLCBha2EgInVzZXIiKQ0KDQoNCkludGVy YWN0aW9uIEFnYWluDQotPiBGb3IgZWFjaCBpbnRlcmFjdGlvbiB0eXBlLCB3ZSB3aWxsIGhhdmUg dG8gZGVzY3JpYmUgdGhlIHByb3RvY29sIGZsb3cgYW5kIHRoZSBuYXR1cmUgYW5kIGJlaGF2aW9y IG9mIGludm9sdmVkIFJvbGVzIChQYXJ0aWVzKSwgRWxlbWVudHMsIFJlcXVlc3RzLg0KW0ZJXSB5 ZXMNCg0KW0ZQXSBXaWxsIHRoZXNlIGFuZCBpbnRvIHRpY2tldHM/DQoNCkJlc3QgcmVnYXJkcy4N Ci9GcmFuY2lzDQoNCg== --_000_FR2P281MB0106C83420ED3F8DF2723BFD8DE30FR2P281MB0106DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxk aXYgY2xhc3M9InhfZ21haWxfcXVvdGUiPg0KPGRpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJxdW90 YWJsZVRleHRUcmFpbmluZyIgc3R5bGU9ImJvcmRlci1sZWZ0OiAzcHggc29saWQgcmdiKDIwMCwg MjAwLCAyMDApOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMjAwLCAyMDAsIDIwMCk7IGJvcmRlci1y aWdodC1jb2xvcjogcmdiKDIwMCwgMjAwLCAyMDApOyBib3JkZXItYm90dG9tLWNvbG9yOiByZ2Io MjAwLCAyMDAsIDIwMCk7IHBhZGRpbmctbGVmdDogMWV4OyBtYXJnaW4tbGVmdDogMC44ZXg7IGNv bG9yOiByZ2IoMTAyLCAxMDIsIDEwMik7Ij4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJnaW46 MHB4O2ZvbnQtc2l6ZToxNXB4O2NvbG9yOnJnYigwLCAwLCAwKTtiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNTUsIDI1NSwgMjU1KSI+DQpPbiBUdWUsIE5vdiAzLCAyMDIwIGF0IDExOjAwIFBNIEZyYW5j aXMgUG91YXRjaGEgJmx0O2Zwbz08YSBocmVmPSJtYWlsdG86NDBhZG9yc3lzLmRlQGRtYXJjLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub29wZW5lciBub3JlZmVycmVyIiBkYXRhLWF1 dGg9Ik5vdEFwcGxpY2FibGUiIHN0eWxlPSJtYXJnaW46MHB4Ij40MGFkb3JzeXMuZGVAZG1hcmMu aWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJn aW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MHB4O2NvbG9yOmJsYWNrIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjow cHg7dGV4dC1hbGlnbjpsZWZ0O2JhY2tncm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOjBweDtjb2xvcjpibGFjayI+QikgQ3VycmVudCBEb2N1bWVudDwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOjBweDtjb2xvcjpibGFjayI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MHB4Ij48Zm9udCBjb2xvcj0iYmxhY2siPlJvbGVzIGRlc2NyaXB0aW9uIHNoYWxsIG5v dCBob2xkIGFueSBhc3N1bXB0aW9uIG9uIHRoZSBwaHlzaWNhbCBzdHJ1Y3R1cmUgb2YgdGhlIHBh cnR5IGZ1bGZpbGxpbmcgdGhlIHJvbGVzLjwvZm9udD4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgi Pjxmb250IGNvbG9yPSJyZWQiPltGSV0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbjwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBz dHlsZT0ibWFyZ2luOjBweDtmb250LXNpemU6MTVweDtjb2xvcjpyZ2IoMCwgMCwgMCk7YmFja2dy b3VuZC1jb2xvcjpyZ2IoMjU1LCAyNTUsIDI1NSkiPg0KJm5ic3A7W0ZQXSBmb3IgZXhhbXBsZSwg d2UgYXNzdW1lIHRoZSBBUyBpcyBhIHNlcnZlciEgSW4gbW9zdCBTU0kgYmFzZWQgdXNlIGNhc2Vz LCB0aGUgQVMgd2lsbCBiZSBydW5uaW5nIG9uIHRoZSB1c2VyIGRldmljZS4gU2VlIFNJT1AgKDxh IGhyZWY9Imh0dHBzOi8vaWRlbnRpdHkuZm91bmRhdGlvbi9kaWQtc2lvcC8iIHRhcmdldD0iX2Js YW5rIiByZWw9Im5vb3BlbmVyIG5vcmVmZXJyZXIiIGRhdGEtYXV0aD0iTm90QXBwbGljYWJsZSIg c3R5bGU9Im1hcmdpbjowcHgiPmh0dHBzOi8vaWRlbnRpdHkuZm91bmRhdGlvbi9kaWQtc2lvcC88 L2E+KS48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7Zm9udC1zaXplOjE1cHg7Y29sb3I6 cmdiKDAsIDAsIDApO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwgMjU1LCAyNTUpIj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDtmb250LXNpemU6MTVweDtjb2xvcjpyZ2IoMCwgMCwg MCk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LCAyNTUsIDI1NSkiPg0KPGJyPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBjbGFzcz0icXVvdGFibGVUZXh0VHJhaW5pbmciIHN0eWxlPSJib3JkZXItbGVm dDogM3B4IHNvbGlkIHJnYigyMDAsIDIwMCwgMjAwKTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIw MCwgMjAwLCAyMDApOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDAsIDIwMCwgMjAwKTsgYm9y ZGVyLWJvdHRvbS1jb2xvcjogcmdiKDIwMCwgMjAwLCAyMDApOyBwYWRkaW5nLWxlZnQ6IDFleDsg bWFyZ2luLWxlZnQ6IDAuOGV4OyBjb2xvcjogcmdiKDEwMiwgMTAyLCAxMDIpOyI+DQo8ZGl2IGRp cj0ibHRyIiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4O2ZvbnQt c2l6ZToxMnB0O2ZvbnQtZmFtaWx5OkNhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDt0ZXh0LWFsaWduOmxlZnQ7 YmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYg c3R5bGU9Im1hcmdpbjowcHgiPlJvbGVzOiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBweCI+LSZndDsgZ3JhbnQgZW5kcG9pbnQgb2YgdGhlIEFTOiBXaHkgaXMgdGhpcyBhIHBvc3Qg cmVxdWVzdD8gVGhpcyBlbGltaW5hdGVzIHRoZSBjaGFuY2Ugb2YgaGF2aW5nIHVzZXIgZGV2aWNl IGhvc3RlZCBBUyAobm8gc2VydmVyKS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+W0ZJXSB3aGF0 IHdvdWxkIHlvdSBwcm9wb3NlIGluc3RlYWQ/PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+V291bGQgYWxzbyBiZSBpbnRlcmVzdGVkIHRvIHVu ZGVyc3RhbmQgYmV0dGVyIHRoZSBkZXBsb3ltZW50IG1vZGVsIHdoZW4gdGhlcmUgaXMgbm8gc2Vy dmVyLiBUaGF0J3Mgc29tZXRoaW5nIHRoYXQgd2FzIGRpc2N1c3NlZCBzZXZlcmFsIHRpbWVzIGJ1 dCBJJ20gc3RpbGwgbWlzc2luZyB0aGUgdW5kZXJseWluZyBhcmNoaXRlY3R1cmUgYW5kIHVzZSBj YXNlLjwvZm9udD48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7 Zm9udC1zaXplOjE1cHg7Y29sb3I6cmdiKDAsIDAsIDApO2JhY2tncm91bmQtY29sb3I6cmdiKDI1 NSwgMjU1LCAyNTUpIj4NCiZuYnNwO1tGUF0gU2VlIGFib3ZlIChTSU9QKS4gVGhlcmUgd2lsbCBi ZSBhIGxvdCBvZiBpZGVudGl0eSB3YWxsZXRzIG9wZXJhdGVkIG9uIGVuZCB1c2VyIGRldmljZS48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7Zm9udC1zaXplOjE1cHg7Y29sb3I6cmdiKDAs IDAsIDApO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwgMjU1LCAyNTUpIj4NCjxicj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9InF1b3RhYmxlVGV4dFRyYWluaW5nIiBzdHlsZT0iYm9yZGVy LWxlZnQ6IDNweCBzb2xpZCByZ2IoMjAwLCAyMDAsIDIwMCk7IGJvcmRlci10b3AtY29sb3I6IHJn YigyMDAsIDIwMCwgMjAwKTsgYm9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAwLCAyMDAsIDIwMCk7 IGJvcmRlci1ib3R0b20tY29sb3I6IHJnYigyMDAsIDIwMCwgMjAwKTsgcGFkZGluZy1sZWZ0OiAx ZXg7IG1hcmdpbi1sZWZ0OiAwLjhleDsgY29sb3I6IHJnYigxMDIsIDEwMiwgMTAyKTsiPg0KPGRp diBkaXI9Imx0ciIgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDtm b250LXNpemU6MTJwdDtmb250LWZhbWlseTpDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7dGV4dC1hbGlnbjps ZWZ0O2JhY2tncm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4tJmd0OyBSZXNvdXJjZSBPd25lciAoUk8pIDogQXV0aG9y aXplcyB0aGUgcmVxdWVzdD8gRG9lcyBpdCBhdXRob3JpemUgdGhlIHJlcXVlc3Qgb3IgdGhlIGFj Y2VzcyB0byBhIHJlc291cmNlPzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj5bRkldIHllcywgd2Ug c2hvdWxkIG1ha2UgdGhlIHdvcmRpbmcgY2xlYXJlcjwvZm9udD48L2Rpdj4NCjxkaXYgZGlyPSJs dHIiIHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7Zm9udC1zaXpl OjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4O3RleHQtYWxpZ246bGVmdDtiYWNr Z3JvdW5kLWNvbG9yOndoaXRlIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOjBweCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij5NaXNz aW5nIFNlY3Rpb24gSW50ZXJhY3Rpb25zOjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+ LS0mZ3Q7IFRoaXMgc2VjdGlvbiBzaGFsbCBpbnRyb2R1Y2UgdGhlIG5vdGlvbiBvZiBpbnRlcmFj dGlvbiBiZWZvcmUgd2Ugc3RhcnQgbGlzdGluZyBpbnRlcmFjdGlvbiB0eXBlcy48L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZv bnQgY29sb3I9InJlZCI+W0ZJXSB5ZXMmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGRpcj0ibHRy IiBzdHlsZT0ibWFyZ2luOjBweDtmb250LXNpemU6MTVweDtjb2xvcjpyZ2IoMCwgMCwgMCk7YmFj a2dyb3VuZC1jb2xvcjpyZ2IoMjU1LCAyNTUsIDI1NSkiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBw eDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTpDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7dGV4dC1hbGln bjpsZWZ0O2JhY2tncm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOjBweDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTpDYWxpYnJpLCBBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjowcHg7dGV4dC1hbGlnbjpsZWZ0O2JhY2tncm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij5JbnRlcmFjdGlvbiBUeXBl czo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPi0tJmd0OyBJIHByZWZlciBhIGNsYXNz aWZpY2F0aW9uIHdpdGggUmVkaXJlY3QsIERlY291cGxlZCBhbmQgRW1iZWRkZWQgaXMuIEluIHRo ZSBkcmFmdCwgd2UgaGF2ZSBvbmUgcmVkaXJlY3QgYW5kIDIgZGVjb3VwbGUgaW50ZXJhY3Rpb25z IGFuZCBub3RoaW5nIGVsc2UuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJyZWQiPltGSV0gdGhpcyBzaG91 bGQgYmUgaGFuZGxlZCBhcyBhIHNwZWNpZmljIGRpc2N1c3Npb24gaXRlbS4gQXMgYSByZW1pbmRl ciwgaG93IHdvdWxkIHlvdSBkZWZpbmUgZW1iZWRkZWQ/PC9mb250PjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBjb2xv cj0icmVkIj5JbiBwcmFjdGljZSB0aGVyZSdzIGF0IGxlYXN0IHRoZXNlIG1vZGVzOjwvZm9udD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJyZWQiPi0gcmVkaXJl Y3QgYW5kIHJlZGlyZWN0IGJhY2s8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4 Ij48Zm9udCBjb2xvcj0icmVkIj4tIHJlZGlyZWN0IHRvIGRpZmZlcmVudCBicm93c2VyIG9yIGRl dmljZTwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJy ZWQiPi0gdXNlciBjb2RlPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZv bnQgY29sb3I9InJlZCI+LSBDSUJBPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4O2ZvbnQtc2l6ZToxNXB4O2NvbG9yOnJnYigwLCAwLCAw KTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsIDI1NSwgMjU1KSI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46MHB4Ij5bRlBdIFRoaXMgY2xhc3NpZmljYXRpb24gaXMgbGltaXRlZC48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDtmb250LXNpemU6MTVweDtjb2xvcjpyZ2IoMCwgMCwg MCk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LCAyNTUsIDI1NSkiPg0KPHVsPg0KPGxpPlJlZGly ZWN0OiBzYW1lIGRldmljZSwgc2FtZSBvciBkaWZmZXJlbnQgdXNlciBhZ2VudHMgKGJyb3dzZXIs IG1vYmlsZSBhcHAsIGRlc2t0b3AgYXBwLCAuLi4pPC9saT48bGk+RGVjb3VwbGVkOiBkaWZmZXJl bnQgZGV2aWNlczwvbGk+PGxpPkVtYmVkZGVkIDogUkMgY2FycmllcyBSTyBhdXRob3JpemF0aW9u IHRvIEFTPC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4O2ZvbnQtc2l6 ZToxNXB4O2NvbG9yOnJnYigwLCAwLCAwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsIDI1NSwg MjU1KSI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJnaW46MHB4Ij4N CjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46MHB4O3RleHQtYWxpZ246bGVmdDtiYWNrZ3JvdW5kLWNvbG9yOndoaXRlIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJx dW90YWJsZVRleHRUcmFpbmluZyIgc3R5bGU9ImJvcmRlci1sZWZ0OiAzcHggc29saWQgcmdiKDIw MCwgMjAwLCAyMDApOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMjAwLCAyMDAsIDIwMCk7IGJvcmRl ci1yaWdodC1jb2xvcjogcmdiKDIwMCwgMjAwLCAyMDApOyBib3JkZXItYm90dG9tLWNvbG9yOiBy Z2IoMjAwLCAyMDAsIDIwMCk7IHBhZGRpbmctbGVmdDogMWV4OyBtYXJnaW4tbGVmdDogMC44ZXg7 IGNvbG9yOiByZ2IoMTAyLCAxMDIsIDEwMik7Ij4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJn aW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MHB4O3RleHQtYWxpZ246bGVmdDtiYWNrZ3JvdW5kLWNvbG9yOndo aXRlIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+ UmVzb3VyY2UgQWNjZXNzIFJlcXVlc3QgdnMuIFJlc291cmNlIFJlcXVlc3Q8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjowcHgiPi0tJmd0OyBCb3RoIGFyZSBtaXhlZCB1cC4gTm8gY2xhcmlmaWNh dGlvbiBvZiB0aGUgY29udGV4dCBvZiBlYWNoIHNlY3Rpb24uPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJy ZWQiPltGSV0gY291bGQgeW91IGNsYXJpZnkgd2hhdCB5b3UnZCBleHBlY3QuJm5ic3A7IEJ0dyBv biB0aGlzIHRvcGljLCB0aGVyZSdzIGEgbW9yZSBnZW5lcmFsIGRpc2N1c3Npb24gb24gd2hldGhl ciB3ZSBzaG91bGQgbWFrZSBhIGRpc3RpbmN0aW9uIG9yIG5vdC4mbmJzcDs8L2ZvbnQ+PC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4O2ZvbnQtc2l6ZToxNXB4O2Nv bG9yOnJnYigwLCAwLCAwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsIDI1NSwgMjU1KSI+DQo8 Zm9udCBjb2xvcj0icmVkIj48c3BhbiBzdHlsZT0ibWFyZ2luOjBweDtjb2xvcjpyZ2IoMCwgMzYs IDgxKSI+4oCLW0ZQXTogSGVyZTo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweDtmb250LXNpemU6MTVweDtjb2xvcjpyZ2IoMCwgMCwgMCk7YmFja2dyb3VuZC1jb2xv cjpyZ2IoMjU1LCAyNTUsIDI1NSkiPg0KPHVsPg0KPGxpPjxmb250IGNvbG9yPSJyZWQiPjxzcGFu IHN0eWxlPSJtYXJnaW46MHB4O2NvbG9yOnJnYigwLCAzNiwgODEpIj48c3BhbiBzdHlsZT0ibWFy Z2luOjBweDtmb250LWZhbWlseTpDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlm O2NvbG9yOmJsYWNrO3RleHQtYWxpZ246bGVmdDtiYWNrZ3JvdW5kLWNvbG9yOndoaXRlIj5SZXNv dXJjZSBBY2Nlc3MgUmVxdWVzdDogUmVxdWVzdGluZyBBY2Nlc3MgdG8gYSByZXNvdXJjZS4gUmVz cG9uc2UNCiBpcyBhbiBhY2Nlc3MgdG9rZW4gKG9yIGFueSB0eXBlIG9mIGdyYW50KTwvc3Bhbj48 L3NwYW4+PC9mb250PjwvbGk+PGxpPjxmb250IGNvbG9yPSJyZWQiPjxzcGFuIHN0eWxlPSJtYXJn aW46MHB4O2NvbG9yOnJnYigwLCAzNiwgODEpIj48c3BhbiBzdHlsZT0ibWFyZ2luOjBweDtmb250 LWZhbWlseTpDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmO2NvbG9yOmJsYWNr O3RleHQtYWxpZ246bGVmdDtiYWNrZ3JvdW5kLWNvbG9yOndoaXRlIj5SZXNvdXJjZSBSZXF1ZXN0 OiBSZXF1ZXN0IHRoZSByZXNvdXJjZS4gUmVzcG9uc2UgaXMgdGhlIHJlc291cmNlDQogKG9yIGEg Y29ycmVzcG9uZGluZyBleGVjdXRpb24pPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9saT48L3VsPg0K PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MHB4O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OkNhbGlicmksIEFyaWFsLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDt0 ZXh0LWFsaWduOmxlZnQ7YmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46MHB4Ij48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJxdW90YWJsZVRleHRUcmFpbmluZyIgc3R5bGU9ImJvcmRlci1sZWZ0OiAzcHggc29s aWQgcmdiKDIwMCwgMjAwLCAyMDApOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMjAwLCAyMDAsIDIw MCk7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIwMCwgMjAwLCAyMDApOyBib3JkZXItYm90dG9t LWNvbG9yOiByZ2IoMjAwLCAyMDAsIDIwMCk7IHBhZGRpbmctbGVmdDogMWV4OyBtYXJnaW4tbGVm dDogMC44ZXg7IGNvbG9yOiByZ2IoMTAyLCAxMDIsIDEwMik7Ij4NCjxkaXYgZGlyPSJsdHIiIHN0 eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7Zm9udC1zaXplOjEycHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4O3RleHQtYWxpZ246bGVmdDtiYWNrZ3JvdW5k LWNvbG9yOndoaXRlIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweCI+VG9rZW4gQ29udGVudCBOZWdvdGlhdGlvbjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweCI+LS0mZ3Q7IE5vdCBleHByZXNzZWQgYXMgc3VjaC4gVGhpcyBpcyBjZW50cmFsIHRv IEdOQVAgYW5kIG5vdCByZXByZXNlbnRlZCBlbm91Z2gmbmJzcDsgaW4gdGhlIGRvY3VtZW50Ljwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 MHB4Ij48Zm9udCBjb2xvcj0icmVkIj5bRkldIHJpZ2h0LiBUaGlzIHNob3VsZCBiZSBhIHNwZWNp ZmljIGRpc2N1c3Npb24gaXRlbS4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBz dHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4O2ZvbnQtc2l6ZToxMnB0 O2ZvbnQtZmFtaWx5OkNhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDt0ZXh0LWFsaWduOmxlZnQ7YmFja2dyb3Vu ZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1h cmdpbjowcHgiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+UmVxdWVzdGlu ZyAmcXVvdDtVc2VyJnF1b3Q7IEluZm9ybWF0aW9uPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 MHB4Ij53ZSBpZGVudGlmeSB0d28gdHlwZXMgb2YgdXNlcnM6IFJRIGFuZCBSTy4gSXQgd2lsbCBi ZSBiZXR0ZXIgbm90IHRvIHJlZmVyIHRvIGEgdXNlciBpbiB0aGlzIGRyYWZ0LCBidXQgZWl0aGVy IHRvIGEgUlEgb3IgYW4gUk8uPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJyZWQiPltGSV0geWVzIHRoYXQg d291bGQgYXZvaWQgcG90ZW50aWFsIG1pc3VuZGVyc3RhbmRpbmdzLiBBbHRob3VnaCBpbiB0aGUg ZW5kLCBwZW9wbGUgd2lsbCB0cmFuc2xhdGUgUlEgaW50byB1c2VyJm5ic3A7b3IgZW5kLXVzZXIg bW9zdCBvZiB0aGUgdGltZS4gQ2YgaW4gZGVmaW5pdGlvbiwgY3VycmVudGx5IHdlIGhhdmUmbmJz cDs8L2ZvbnQ+PHNwYW4gc3R5bGU9Im1hcmdpbjowcHg7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1p bHk6JnF1b3Q7Tm90byBTYW5zJnF1b3Q7LCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48 Zm9udCBjb2xvcj0icmVkIj5SZXF1ZXN0aW5nDQogUGFydHkgKFJRLCBha2EgJnF1b3Q7dXNlciZx dW90Oyk8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGJyPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9Im1h cmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDtmb250LXNpemU6MTJwdDtmb250LWZh bWlseTpDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7dGV4dC1hbGlnbjpsZWZ0O2JhY2tncm91bmQtY29sb3I6 d2hpdGUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4 Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPkludGVyYWN0aW9uIEFnYWlu PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgi Pi0mZ3Q7IEZvciBlYWNoIGludGVyYWN0aW9uIHR5cGUsIHdlIHdpbGwgaGF2ZSB0byBkZXNjcmli ZSB0aGUgcHJvdG9jb2wgZmxvdyBhbmQgdGhlIG5hdHVyZSBhbmQgYmVoYXZpb3Igb2YgaW52b2x2 ZWQgUm9sZXMgKFBhcnRpZXMpLCBFbGVtZW50cywgUmVxdWVzdHMuPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZv bnQgY29sb3I9InJlZCI+W0ZJXSB5ZXMmbmJzcDsmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MHB4O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OkNhbGlicmksIEFyaWFsLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDt0 ZXh0LWFsaWduOmxlZnQ7YmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4O2ZvbnQtc2l6ZTox NXB4O2NvbG9yOnJnYigwLCAwLCAwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsIDI1NSwgMjU1 KSI+DQpbRlBdIFdpbGwgdGhlc2UgYW5kIGludG8gdGlja2V0cz88L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjowcHg7Zm9udC1zaXplOjE1cHg7Y29sb3I6cmdiKDAsIDAsIDApO2JhY2tncm91bmQt Y29sb3I6cmdiKDI1NSwgMjU1LCAyNTUpIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweDtmb250LXNpemU6MTVweDtjb2xvcjpyZ2IoMCwgMCwgMCk7YmFja2dyb3VuZC1jb2xv cjpyZ2IoMjU1LCAyNTUsIDI1NSkiPg0KQmVzdCByZWdhcmRzLjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOjBweDtmb250LXNpemU6MTVweDtjb2xvcjpyZ2IoMCwgMCwgMCk7YmFja2dyb3VuZC1j b2xvcjpyZ2IoMjU1LCAyNTUsIDI1NSkiPg0KL0ZyYW5jaXM8L2Rpdj4NCjxicj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FR2P281MB0106C83420ED3F8DF2723BFD8DE30FR2P281MB0106DEUP_-- From nobody Tue Nov 17 08:45: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 9F0463A14C4 for ; Tue, 17 Nov 2020 08:45:07 -0800 (PST) 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, NICE_REPLY_A=-0.001, 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 Olc0EySV6zuU for ; Tue, 17 Nov 2020 08:45:06 -0800 (PST) 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 19DB83A14BD for ; Tue, 17 Nov 2020 08:45:04 -0800 (PST) Received: from [192.168.1.11] ([90.79.50.181]) by mwinf5d17 with ME id tUl02300D3uZx0A03Ul0FV; Tue, 17 Nov 2020 17:45:03 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 17 Nov 2020 17:45:03 +0100 X-ME-IP: 90.79.50.181 To: txauth@ietf.org References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> From: Denis Message-ID: <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> Date: Tue, 17 Nov 2020 17:45:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F4AF729AAB34394E7A38DC5D" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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: Tue, 17 Nov 2020 16:45:08 -0000 This is a multi-part message in MIME format. --------------F4AF729AAB34394E7A38DC5D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello  Francis, See two comments in line. > > B) Current Document > > Roles description shall not hold any assumption on the physical > structure of the party fulfilling the roles. > [FI] not sure what you mean > >  [FP] for example, we assume the AS is a server! In most SSI based use > cases, the AS will be running on the user device. See SIOP > (https://identity.foundation/did-siop/). I browsed through the two drafts, i.e. : * Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020 * Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft At no place within these two documents, it is possible to imagine that "the AS will be running on the user device". From section 3 of the DIF Working Group Draft:       "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP". An Identity Wallet is not an AS. > > Roles: > -> grant endpoint of the AS: Why is this a post request? This > eliminates the chance of having user device hosted AS (no server). > [FI] what would you propose instead? > Would also be interested to understand better the deployment model > when there is no server. That's something that was discussed > several times but I'm still missing the underlying architecture > and use case. > >  [FP] See above (SIOP). There will be a lot of identity wallets > operated on end user device. See the above comment. Please, do not confuse an Identity Wallet with an Authentication Server (AS). Denis > > -> Resource Owner (RO) : Authorizes the request? Does it authorize > the request or the access to a resource? > [FI] yes, we should make the wording clearer > > Missing Section Interactions: > --> This section shall introduce the notion of interaction before > we start listing interaction types. > [FI] yes > > Interaction Types: > --> I prefer a classification with Redirect, Decoupled and > Embedded is. In the draft, we have one redirect and 2 decouple > interactions and nothing else. > [FI] this should be handled as a specific discussion item. As a > reminder, how would you define embedded? > > In practice there's at least these modes: > - redirect and redirect back > - redirect to different browser or device > - user code > - CIBA > > [FP] This classification is limited. > > * Redirect: same device, same or different user agents (browser, > mobile app, desktop app, ...) > * Decoupled: different devices > * Embedded : RC carries RO authorization to AS > > > > Resource Access Request vs. Resource Request > --> Both are mixed up. No clarification of the context of each > section. > [FI] could you clarify what you'd expect.  Btw on this topic, > there's a more general discussion on whether we should make a > distinction or not. > > ​[FP]: Here: > > * Resource Access Request: Requesting Access to a resource. Response > is an access token (or any type of grant) > * Resource Request: Request the resource. Response is the resource > (or a corresponding execution) > > > Token Content Negotiation > --> Not expressed as such. This is central to GNAP and not > represented enough  in the document. > [FI] right. This should be a specific discussion item. > > Requesting "User" Information > we identify two types of users: RQ and RO. It will be better not > to refer to a user in this draft, but either to a RQ or an RO. > [FI] yes that would avoid potential misunderstandings. Although in > the end, people will translate RQ into user or end-user most of > the time. Cf in definition, currently we have Requesting Party > (RQ, aka "user") > > > Interaction Again > -> For each interaction type, we will have to describe the > protocol flow and the nature and behavior of involved Roles > (Parties), Elements, Requests. > [FI] yes > > > [FP] Will these and into tickets? > > Best regards. > /Francis > > --------------F4AF729AAB34394E7A38DC5D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello  Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
 [FP] for example, we assume the AS is a server! In most SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagine that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

      "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.


Roles: 
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
 [FP] See above (SIOP). There will be a lot of identity wallets operated on end user device.

See the above comment. Please, do not confuse an Identity Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes 

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could you clarify what you'd expect.  Btw on this topic, there's a more general discussion on whether we should make a distinction or not. 
​[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough  in the document.
[FI] right. This should be a specific discussion item. 

Requesting "User" Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user or end-user most of the time. Cf in definition, currently we have Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes  

[FP] Will these and into tickets?

Best regards.
/Francis



--------------F4AF729AAB34394E7A38DC5D-- From nobody Tue Nov 17 09:03:54 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 64F4B3A149E for ; Tue, 17 Nov 2020 09:03:52 -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 kzvv7fr0JwO2 for ; Tue, 17 Nov 2020 09:03:50 -0800 (PST) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 382D23A147A for ; Tue, 17 Nov 2020 09:03:50 -0800 (PST) Received: by mail-ej1-x62b.google.com with SMTP id gj5so2957847ejb.8 for ; Tue, 17 Nov 2020 09:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=68Jx+X5Bff/9vROqn2I5HRq5HGt/atKekAhXEuUvaBY=; b=l/VFnZinMo4zRENTAUK4J0YRI9cNxrSi36o18Ldq5FJBkCv7VZ5xPvGGprTwfhgVSK HvQ3/xEcjRS0ZsfxbHG4BMILOjZt54OZBreb2KXbDdkE+eZiFWD9Mc2JO1U+RY/mQP17 UxqgQdqjOGykUyfA0SzJ4WqiaiHFOPwwVotuUQ1UFFmpTrbfRWRkHMU/QTwPMapy9vF8 br3XJ4R9TIRLUxsX6R7vGivpHRcQ+9WS5Z8h9yLuGkwHOUFeUxqccXcVTxWffuaDgomp TIN/3DDGunpTSdpMgt513nuilu7B76ATYnEpQtIDLzJ08ydDbK7i+BqdWTuwd5AyNXn9 tuXw== 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=68Jx+X5Bff/9vROqn2I5HRq5HGt/atKekAhXEuUvaBY=; b=j0taSm0+VyCQDiCiwjKidPbNbpbrUjhf+TI/RB0l/a555ZTUQqhcS3znaUKhQXsqW0 Y4/9Zl1RrFhzOgSdPnq2vEpcWh7M7yKxZXRQbKifpFmngubKlXyrMLVmVKLxaVgOCByX Z/1AS697TB0z2C+YnbjeQqYNegiSqzqTXcqBcvb1M+28uALjRVqsEi62HPwzU9WqaiB+ b4AKvtA40mVX13fGa4luVBJhK0cX0NY18EOhpEY0uTvxfcfhiEgLJ5itEoWJXBlYH77w knFcmj1FUWO37C0PAWi1HHG4SnCHT0/A/o5AAzhk9xMtqPGxtbEaQSiImBbgaPCgNMLN UJ4w== X-Gm-Message-State: AOAM530HuWmda168IFU5A7lh7Uv0okMZdBJHgkzS3OgZ1A0+/YbF5A/x vZIyrmKKKyVQ30pQY3mo9dtAaBIlMLXk408ZeBE= X-Google-Smtp-Source: ABdhPJxna0RrqFvUOSn9hShehMOdi6t4Ll3QBDh6nf0GiSQZ8JU0emUN6POARWAJX2u8ytGddlHGSMWGsT8WsF2gCi0= X-Received: by 2002:a17:906:892:: with SMTP id n18mr19621068eje.1.1605632628573; Tue, 17 Nov 2020 09:03:48 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> In-Reply-To: <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> From: Fabien Imbault Date: Tue, 17 Nov 2020 18:03:35 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000774cc905b4507a0f" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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: Tue, 17 Nov 2020 17:03:52 -0000 --000000000000774cc905b4507a0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, hi Francis, At some point integration with SSI (on the authentication side) will probably occur, including amongst other possibilities SIOP (since they work with OpenID a part of the work will probably be made easier). That being said, Denis is right. It's not an AS. Technically it's entirely possible to rely on a decentralized wallet (for instance on your phone) and a centralized AS. I know of a few studies on how to decentralize the AS itself (for instance https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). Maybe it exists, but I'm still looking for real scenarios (or even architectures) where an AS is deployed directly on a phone, and under the sole authority of the RO, while being compatible with the rest of the world. Cheers, Fabien On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: > Hello Francis, > > See two comments in line. > > > B) Current Document > > Roles description shall not hold any assumption on the physical structure > of the party fulfilling the roles. > [FI] not sure what you mean > > [FP] for example, we assume the AS is a server! In most SSI based use > cases, the AS will be running on the user device. See SIOP ( > https://identity.foundation/did-siop/). > > I browsed through the two drafts, i.e. : > > - Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, > and representations W3C Working Draft 08 November 2020 > - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working > Group Draft > > At no place within these two documents, it is possible to imagine that > "the AS will be running on the user device". > > From section 3 of the DIF Working Group Draft: > > "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the > SIOP will not return an access token to the RP". > > An Identity Wallet is not an AS. > > > Roles: > -> grant endpoint of the AS: Why is this a post request? This eliminates > the chance of having user device hosted AS (no server). > [FI] what would you propose instead? > Would also be interested to understand better the deployment model when > there is no server. That's something that was discussed several times but > I'm still missing the underlying architecture and use case. > > [FP] See above (SIOP). There will be a lot of identity wallets operated > on end user device. > > See the above comment. Please, do not confuse an Identity Wallet with an > Authentication Server (AS). > > Denis > > > -> Resource Owner (RO) : Authorizes the request? Does it authorize the > request or the access to a resource? > [FI] yes, we should make the wording clearer > > Missing Section Interactions: > --> This section shall introduce the notion of interaction before we star= t > listing interaction types. > [FI] yes > > Interaction Types: > --> I prefer a classification with Redirect, Decoupled and Embedded is. I= n > the draft, we have one redirect and 2 decouple interactions and nothing > else. > [FI] this should be handled as a specific discussion item. As a reminder, > how would you define embedded? > > In practice there's at least these modes: > - redirect and redirect back > - redirect to different browser or device > - user code > - CIBA > > [FP] This classification is limited. > > - Redirect: same device, same or different user agents (browser, > mobile app, desktop app, ...) > - Decoupled: different devices > - Embedded : RC carries RO authorization to AS > > > > Resource Access Request vs. Resource Request > --> Both are mixed up. No clarification of the context of each section. > [FI] could you clarify what you'd expect. Btw on this topic, there's a > more general discussion on whether we should make a distinction or not. > > =E2=80=8B[FP]: Here: > > - Resource Access Request: Requesting Access to a resource. Response > is an access token (or any type of grant) > - Resource Request: Request the resource. Response is the resource (or > a corresponding execution) > > > Token Content Negotiation > --> Not expressed as such. This is central to GNAP and not represented > enough in the document. > [FI] right. This should be a specific discussion item. > > Requesting "User" Information > we identify two types of users: RQ and RO. It will be better not to refer > to a user in this draft, but either to a RQ or an RO. > [FI] yes that would avoid potential misunderstandings. Although in the > end, people will translate RQ into user or end-user most of the time. Cf = in > definition, currently we have Requesting Party (RQ, aka "user") > > > Interaction Again > -> For each interaction type, we will have to describe the protocol flow > and the nature and behavior of involved Roles (Parties), Elements, Reques= ts. > [FI] yes > > > [FP] Will these and into tickets? > > Best regards. > /Francis > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000774cc905b4507a0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis, hi Francis,=C2=A0

At some poi= nt integration with SSI (on the authentication side) will probably occur, i= ncluding amongst other possibilities SIOP (since they work with OpenID a pa= rt of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it's= entirely possible to rely on a decentralized wallet (for instance on your = phone) and a centralized AS. I know of a few studies on how to decentralize= the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hard= jono-oauth-decentralized-02).
Maybe it exists, but I'm st= ill looking for real scenarios (or even architectures) where an AS is deplo= yed directly on a phone, and under the sole authority of the RO, while bein= g compatible with the rest of the world.=C2=A0

Che= ers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
=
=20 =20 =20
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
=C2=A0[FP] for example, we assume the AS is a server! In mo= st SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagine that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization C= ode Flow as per [OIDC.Core], the SIOP will not return an access token to the RP"= .

An Identity Wallet is not an AS.


Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
=C2=A0[FP] See above (SIOP). There will be a lot of identit= y wallets operated on end user device.

See the above comment. Please, do not confuse an Identity Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes=C2= =A0

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code=
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could yo= u clarify what you'd expect.=C2=A0 Btw on this topic, there's a more general discussion on whether we should make a distinction or not.=C2=A0
=E2=80=8B[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a specific discussion item.=C2=A0=

Requesting "User&quo= t; Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user=C2=A0or end-user most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes=C2= =A0=C2=A0

[FP] Will these and into tickets?

Best regards.
/Francis



--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000774cc905b4507a0f-- From nobody Tue Nov 17 09:19: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 E25383A15B3 for ; Tue, 17 Nov 2020 09:19:09 -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_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 23tdnUi9MrWV for ; Tue, 17 Nov 2020 09:19:07 -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 DE2CB3A1564 for ; Tue, 17 Nov 2020 09:19:05 -0800 (PST) Received: from [192.168.1.19] (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 0AHHJ07a027295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Nov 2020 12:19:00 -0500 From: Justin Richer Message-Id: <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_7461F44E-B264-4FF2-AF07-0D9E424C7DE3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 17 Nov 2020 12:19:00 -0500 In-Reply-To: Cc: Denis , GNAP Mailing List To: Fabien Imbault References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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: Tue, 17 Nov 2020 17:19:15 -0000 --Apple-Mail=_7461F44E-B264-4FF2-AF07-0D9E424C7DE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ultimately, in most situations like these in the real world, the hurdle = isn=E2=80=99t technical compatibility so much as it is trust = compatibility. The RP (client) needs to have some incentive to trust the = assertions and identity information that=E2=80=99s coming from the AS. = The same is true for an RS trusting tokens from the AS. The hard = question is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), = but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t = answer very well, because it=E2=80=99s a hard question). Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of = it more than OAuth2/OIDC have by allowing the bootstrap of the process = from a starting call: the interaction and continuation URIs handed back = by the AS don=E2=80=99t need to be the same URIs that the client starts = with, so just like SIOP the process can start in HTTP and potentially = move to other communication channels. A major difference is that we = aren=E2=80=99t dependent on the assumption that the user will always be = in a browser at some stage, and so the whole raft of front-channel = messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve= got an opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a = concrete proposal as to how that would work over specific protocols, = starting with what we=E2=80=99ve got today.=20 =E2=80=94 Justin > On Nov 17, 2020, at 12:03 PM, Fabien Imbault = wrote: >=20 > Hi Denis, hi Francis,=20 >=20 > At some point integration with SSI (on the authentication side) will = probably occur, including amongst other possibilities SIOP (since they = work with OpenID a part of the work will probably be made easier).=20 >=20 > That being said, Denis is right. It's not an AS. Technically it's = entirely possible to rely on a decentralized wallet (for instance on = your phone) and a centralized AS. I know of a few studies on how to = decentralize the AS itself (for instance = https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02 = ). > Maybe it exists, but I'm still looking for real scenarios (or even = architectures) where an AS is deployed directly on a phone, and under = the sole authority of the RO, while being compatible with the rest of = the world.=20 >=20 > Cheers, > Fabien >=20 > On Tue, Nov 17, 2020 at 5:45 PM Denis > wrote: > Hello Francis, >=20 > See two comments in line. >=20 >>=20 >> B) Current Document >>=20 >> Roles description shall not hold any assumption on the physical = structure of the party fulfilling the roles. >> [FI] not sure what you mean >> [FP] for example, we assume the AS is a server! In most SSI based = use cases, the AS will be running on the user device. See SIOP = (https://identity.foundation/did-siop/ = ). > I browsed through the two drafts, i.e. : >=20 > Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, = and representations W3C Working Draft 08 November 2020 > Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft > At no place within these two documents, it is possible to imagine that = "the AS will be running on the user device". >=20 > =46rom section 3 of the DIF Working Group Draft: >=20 > "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the = SIOP will not return an access token to the RP". >=20 > An Identity Wallet is not an AS.=20 >=20 >>=20 >> Roles:=20 >> -> grant endpoint of the AS: Why is this a post request? This = eliminates the chance of having user device hosted AS (no server). >> [FI] what would you propose instead? >> Would also be interested to understand better the deployment model = when there is no server. That's something that was discussed several = times but I'm still missing the underlying architecture and use case. >> [FP] See above (SIOP). There will be a lot of identity wallets = operated on end user device. > See the above comment. Please, do not confuse an Identity Wallet with = an Authentication Server (AS). >=20 > Denis >=20 >>=20 >> -> Resource Owner (RO) : Authorizes the request? Does it authorize = the request or the access to a resource? >> [FI] yes, we should make the wording clearer >>=20 >> Missing Section Interactions: >> --> This section shall introduce the notion of interaction before we = start listing interaction types. >> [FI] yes=20 >>=20 >> Interaction Types: >> --> I prefer a classification with Redirect, Decoupled and Embedded = is. In the draft, we have one redirect and 2 decouple interactions and = nothing else. >> [FI] this should be handled as a specific discussion item. As a = reminder, how would you define embedded? >>=20 >> In practice there's at least these modes: >> - redirect and redirect back >> - redirect to different browser or device >> - user code >> - CIBA >> [FP] This classification is limited. >> Redirect: same device, same or different user agents (browser, mobile = app, desktop app, ...) >> Decoupled: different devices >> Embedded : RC carries RO authorization to AS >>=20 >>=20 >> Resource Access Request vs. Resource Request >> --> Both are mixed up. No clarification of the context of each = section. >> [FI] could you clarify what you'd expect. Btw on this topic, there's = a more general discussion on whether we should make a distinction or = not.=20 >> =E2=80=8B[FP]: Here: >> Resource Access Request: Requesting Access to a resource. Response is = an access token (or any type of grant) >> Resource Request: Request the resource. Response is the resource (or = a corresponding execution) >>=20 >> Token Content Negotiation >> --> Not expressed as such. This is central to GNAP and not = represented enough in the document. >> [FI] right. This should be a specific discussion item.=20 >>=20 >> Requesting "User" Information >> we identify two types of users: RQ and RO. It will be better not to = refer to a user in this draft, but either to a RQ or an RO. >> [FI] yes that would avoid potential misunderstandings. Although in = the end, people will translate RQ into user or end-user most of the = time. Cf in definition, currently we have Requesting Party (RQ, aka = "user") >>=20 >>=20 >> Interaction Again >> -> For each interaction type, we will have to describe the protocol = flow and the nature and behavior of involved Roles (Parties), Elements, = Requests. >> [FI] yes =20 >>=20 >> [FP] Will these and into tickets? >>=20 >> Best regards. >> /Francis >>=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=_7461F44E-B264-4FF2-AF07-0D9E424C7DE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ultimately, in most situations like these in the real world, = the hurdle isn=E2=80=99t technical compatibility so much as it is trust = compatibility. The RP (client) needs to have some incentive to trust the = assertions and identity information that=E2=80=99s coming from the AS. = The same is true for an RS trusting tokens from the AS. The hard = question is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), = but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t = answer very well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s = definitely a question about how to support this =E2=80=9CAS on device=E2=80= =9D element. We=E2=80=99ve got the start of it more than OAuth2/OIDC = have by allowing the bootstrap of the process from a starting call: the = interaction and continuation URIs handed back by the AS don=E2=80=99t = need to be the same URIs that the client starts with, so just like SIOP = the process can start in HTTP and potentially move to other = communication channels. A major difference is that we aren=E2=80=99t = dependent on the assumption that the user will always be in a browser at = some stage, and so the whole raft of front-channel messages that SIOP = relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an = opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a = concrete proposal as to how that would work over specific protocols, = starting with what we=E2=80=99ve got today. 
 =E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Denis, hi Francis, 

At some point = integration with SSI (on the authentication side) will probably occur, = including amongst other possibilities SIOP (since they work with OpenID = a part of the work will probably be made easier). 

That being said, Denis = is right. It's not an AS. Technically it's entirely possible to rely on = a decentralized wallet (for instance on your phone) and a centralized = AS. I know of a few studies on how to decentralize the AS itself (for = instance https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-= 02).
Maybe it exists, but I'm still looking for = real scenarios (or even architectures) where an AS is deployed directly = on a phone, and under the sole authority of the RO, while being = compatible with the rest of the world. 

Cheers,
Fabien

On Tue, Nov = 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hello  Francis,

See two comments in line.


=
B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
 [FP] for example, we assume the AS is a server! In = most SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. = :

  • Decentralized Identifiers (DIDs) v1.0 Core = architecture, data model, and representations W3C Working Draft 08 November 2020 =
  • Self-Issued OpenID Connect Provider DID Profile = v0.1. DIF Working Group Draft

At no place within these two documents, it is = possible to imagine that "the AS will be running on the user device".

=46rom section 3 of the DIF Working Group = Draft:

      "Unlike the OIDC = Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the = RP".

An Identity Wallet is not an AS.


Roles: 
-> grant = endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
 [FP] See above (SIOP). There will be a lot of = identity wallets operated on end user device.

See the above comment. Please, do not = confuse an Identity Wallet with an Authentication Server (AS).

Denis


-> = Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing = Section Interactions:
--> This = section shall introduce the notion of interaction before we start listing interaction = types.
[FI] yes 

Interaction = Types:
--> I = prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define = embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code
- CIBA
[FP] This = classification is limited.
  • Redirect: same device, same or = different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization = to AS


=
Resource = Access Request vs. Resource Request
--> Both = are mixed up. No clarification of the context of each section.
[FI] could you clarify what you'd expect.  Btw on this topic, there's a more general discussion on whether we should make a distinction or not. 
=E2=80=8B[FP]: = Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding = execution)

Token = Content Negotiation
--> Not = expressed as such. This is central to GNAP and not represented enough  in the = document.
[FI] right. This should be a specific discussion = item. 

Requesting = "User" Information
we identify = two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user or end-user most of the time. Cf in definition, currently we have Requesting Party (RQ, aka = "user")


Interaction = Again
-> For = each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes  

=
[FP] Will these and into tickets?

Best regards.
/Francis



--
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=_7461F44E-B264-4FF2-AF07-0D9E424C7DE3-- From nobody Tue Nov 17 09:46: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 5DA923A14FE for ; Tue, 17 Nov 2020 09:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=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 jIIh3sNnWNs5 for ; Tue, 17 Nov 2020 09:46:21 -0800 (PST) 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 A4AAD3A1597 for ; Tue, 17 Nov 2020 09:46:18 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id 79so20238549otc.7 for ; Tue, 17 Nov 2020 09:46:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TpIwudtZMStHgVbG2oix2tW/rmYb8LUMAAMqgw+pfh4=; b=GPfA+salF/TLhXvItAsqyAVU8K/zZw5GZwqf23CUHcoPIAY0uNYbJqK2ASLxyqsjIs rB2rqJtpNBOlmwCrOUljzMPHW6fWSwDVzYCUHhH+O74JACEI9tsskWuEEe3QIWCnSmtu t79JKSlt9Wwegd8eGqJHpyIoj4DmR6WEksE0NdUb7FJ/l8D/J4yMgVjI1szNRRIeDLNt j/PYebGw+LrZOmlR3ixb12kRajAY5WuMlPuMLmiMNj7bUWFeMtzVMhav3300y038qnk+ CrubPkz6yNXzQkBh9DsFRVVLF3/yuBEMEv787RWdLjfjz4cKS1CWtLu1a8eSRJeUZU3c V1kA== 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=TpIwudtZMStHgVbG2oix2tW/rmYb8LUMAAMqgw+pfh4=; b=AusTXkZWchnBrSqWjAHb2J+T2Rx5D5yfNViFVowCieyCKfexWYkmmaEzgUTHuzLw+1 Ba5N/1L6Y71kImQuCaTZGcSRzVL5cQtAMHwXjqprwccKE/Uza0Qlo1bTxvQhI0/7yfSO qp4yDbLS24wngezp+0g4uxX3gn/Y7rbj4ZIZjWUzKYicTeihliaH+rxLIKCL1GBwdu5o Pfw4zvckucI/du+sJJWP46EW3He55A7Sba3aNNinoBvKgzrb/ohRFqnQP947+3/FHUWg Q91AneOK1pQl0H7ZQeMSs2DpcaIObLCyE3pbxTUyRqNeznEkLNkyElnxelyx+xU/z+Zy fMBA== X-Gm-Message-State: AOAM532jU86neCVxsPWvWKIaeaIBMbamD8jClkjnMDP82vXhEMwOtdTp PXnYiCrVLEvHOiAtjGbs1nlXKcAo7DUB3bu8CwM= X-Google-Smtp-Source: ABdhPJxlPcgtm0EO0lf09nBr9CdDC2TRoIVcBu6l2FPVsaSpuSiBgHtWzaXrE2Qny7EwuSOGmyEaDZPnY4DmrqSIh+Q= X-Received: by 2002:a05:6830:1015:: with SMTP id a21mr3981680otp.143.1605635177819; Tue, 17 Nov 2020 09:46:17 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> From: Tom Jones Date: Tue, 17 Nov 2020 09:46:06 -0800 Message-ID: To: Justin Richer Cc: Fabien Imbault , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000069b14305b451121f" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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: Tue, 17 Nov 2020 17:46:24 -0000 --00000000000069b14305b451121f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, here's a demo. Note that in this case the AS is not online all of the time, so it is really implicit flow and the OIDC id-token comes from the siop device directly. (whether this is front-channel or back channel is no longer an interesting question.) Now if an always-on AS is required, that is possible, but probably beyond the scope of this effort and would require something like an agent-in-the-sky (with diamonds). here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 Peace ..tom On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: > Ultimately, in most situations like these in the real world, the hurdle > isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP > (client) needs to have some incentive to trust the assertions and identit= y > information that=E2=80=99s coming from the AS. The same is true for an RS= trusting > tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to do= that (which SSI > answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, > because it=E2=80=99s a hard question). > > Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on device=E2=80=9D > element. We=E2=80=99ve got the start of it more than OAuth2/OIDC have by = allowing > the bootstrap of the process from a starting call: the interaction and > continuation URIs handed back by the AS don=E2=80=99t need to be the same= URIs that > the client starts with, so just like SIOP the process can start in HTTP a= nd > potentially move to other communication channels. A major difference is > that we aren=E2=80=99t dependent on the assumption that the user will alw= ays be in > a browser at some stage, and so the whole raft of front-channel messages > that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an = opportunity to > more explicitly open up alternative communication channels here, and that= =E2=80=99s > something I=E2=80=99d like to see engineered, even if it=E2=80=99s an ext= ension. I=E2=80=99d love > to see a concrete proposal as to how that would work over specific > protocols, starting with what we=E2=80=99ve got today. > > =E2=80=94 Justin > > On Nov 17, 2020, at 12:03 PM, Fabien Imbault > wrote: > > Hi Denis, hi Francis, > > At some point integration with SSI (on the authentication side) will > probably occur, including amongst other possibilities SIOP (since they wo= rk > with OpenID a part of the work will probably be made easier). > > That being said, Denis is right. It's not an AS. Technically it's entirel= y > possible to rely on a decentralized wallet (for instance on your phone) a= nd > a centralized AS. I know of a few studies on how to decentralize the AS > itself (for instance > https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). > Maybe it exists, but I'm still looking for real scenarios (or even > architectures) where an AS is deployed directly on a phone, and under the > sole authority of the RO, while being compatible with the rest of the > world. > > Cheers, > Fabien > > On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: > >> Hello Francis, >> >> See two comments in line. >> >> >> B) Current Document >> >> Roles description shall not hold any assumption on the physical structur= e >> of the party fulfilling the roles. >> [FI] not sure what you mean >> >> [FP] for example, we assume the AS is a server! In most SSI based use >> cases, the AS will be running on the user device. See SIOP ( >> https://identity.foundation/did-siop/). >> >> I browsed through the two drafts, i.e. : >> >> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >> model, and representations W3C Working Draft 08 November 2020 >> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >> Group Draft >> >> At no place within these two documents, it is possible to imagine that >> "the AS will be running on the user device". >> >> From section 3 of the DIF Working Group Draft: >> >> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >> SIOP will not return an access token to the RP". >> >> An Identity Wallet is not an AS. >> >> >> Roles: >> -> grant endpoint of the AS: Why is this a post request? This eliminates >> the chance of having user device hosted AS (no server). >> [FI] what would you propose instead? >> Would also be interested to understand better the deployment model when >> there is no server. That's something that was discussed several times bu= t >> I'm still missing the underlying architecture and use case. >> >> [FP] See above (SIOP). There will be a lot of identity wallets operated >> on end user device. >> >> See the above comment. Please, do not confuse an Identity Wallet with an >> Authentication Server (AS). >> >> Denis >> >> >> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >> request or the access to a resource? >> [FI] yes, we should make the wording clearer >> >> Missing Section Interactions: >> --> This section shall introduce the notion of interaction before we >> start listing interaction types. >> [FI] yes >> >> Interaction Types: >> --> I prefer a classification with Redirect, Decoupled and Embedded is. >> In the draft, we have one redirect and 2 decouple interactions and nothi= ng >> else. >> [FI] this should be handled as a specific discussion item. As a reminder= , >> how would you define embedded? >> >> In practice there's at least these modes: >> - redirect and redirect back >> - redirect to different browser or device >> - user code >> - CIBA >> >> [FP] This classification is limited. >> >> - Redirect: same device, same or different user agents (browser, >> mobile app, desktop app, ...) >> - Decoupled: different devices >> - Embedded : RC carries RO authorization to AS >> >> >> >> Resource Access Request vs. Resource Request >> --> Both are mixed up. No clarification of the context of each section. >> [FI] could you clarify what you'd expect. Btw on this topic, there's a >> more general discussion on whether we should make a distinction or not. >> >> =E2=80=8B[FP]: Here: >> >> - Resource Access Request: Requesting Access to a resource. Response >> is an access token (or any type of grant) >> - Resource Request: Request the resource. Response is the resource >> (or a corresponding execution) >> >> >> Token Content Negotiation >> --> Not expressed as such. This is central to GNAP and not represented >> enough in the document. >> [FI] right. This should be a specific discussion item. >> >> Requesting "User" Information >> we identify two types of users: RQ and RO. It will be better not to refe= r >> to a user in this draft, but either to a RQ or an RO. >> [FI] yes that would avoid potential misunderstandings. Although in the >> end, people will translate RQ into user or end-user most of the time. Cf= in >> definition, currently we have Requesting Party (RQ, aka "user") >> >> >> Interaction Again >> -> For each interaction type, we will have to describe the protocol flow >> and the nature and behavior of involved Roles (Parties), Elements, Reque= sts. >> [FI] yes >> >> >> [FP] Will these and into tickets? >> >> Best regards. >> /Francis >> >> >> >> -- >> 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 > --00000000000069b14305b451121f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channe= l or back channel is no longer an interesting question.)
Now if an = always-on AS is required, that is possible, but probably beyond the scope o= f this effort and would require something like an agent-in-the-sky=C2=A0(wi= th diamonds).
here is the link to = the 9 min video=C2=A0=C2=A0=C2=A0https://youtu.be/Tq4hw7X5SW0=
=
Peace ..tom


On= Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situation= s like these in the real world, the hurdle isn=E2=80=99t technical compatib= ility so much as it is trust compatibility. The RP (client) needs to have s= ome incentive to trust the assertions and identity information that=E2=80= =99s coming from the AS. The same is true for an RS trusting tokens from th= e AS. The hard question is less =E2=80=9Chow=E2=80=9D to do that (which SSI= answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80= =99t answer very well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS d= on=E2=80=99t need to be the same URIs that the client starts with, so just = like SIOP the process can start in HTTP and potentially move to other commu= nication channels. A major difference is that we aren=E2=80=99t dependent o= n the assumption that the user will always be in a browser at some stage, a= nd so the whole raft of front-channel messages that SIOP relies on doesn=E2= =80=99t fly. That said, we=E2=80=99ve got an opportunity to more explicitly= open up alternative communication channels here, and that=E2=80=99s someth= ing I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. = I=E2=80=99d love to see a concrete proposal as to how that would work over = specific protocols, starting with what we=E2=80=99ve got today.=C2=A0
=

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com= > wrote:

Hi Denis, hi Francis,=C2=A0
=
At some point integration with SSI (on the authentication si= de) will probably occur, including amongst other possibilities SIOP (since = they work with OpenID a part of the work will probably be made easier).=C2= =A0

That being said, Denis is right. It's not = an AS. Technically it's entirely possible to rely on a decentralized wa= llet (for instance on your phone) and a centralized AS. I know of a few stu= dies on how to decentralize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02).


On = Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
=C2=A0[FP] for example, we assume the AS is a server! In mo= st SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagi= ne that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP"= .

An Identity Wallet is not an AS.


Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
=C2=A0[FP] See above (SIOP). There will be a lot of identit= y wallets operated on end user device.

See the above comment. Please, do not confuse an Identi= ty Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes=C2= =A0

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code=
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could yo= u clarify what you'd expect.=C2=A0 Btw on this topic, there's a more general discussion on whether we should make a distinction or not.=C2=A0
=E2=80=8B[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a specific discussion item.=C2=A0=

Requesting "User&quo= t; Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user=C2=A0or end-user most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes=C2= =A0=C2=A0

[FP] Will these and into tickets?

Best regards.
/Francis



--
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
--00000000000069b14305b451121f-- From nobody Tue Nov 17 09:59: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 9B2383A0E8D for ; Tue, 17 Nov 2020 09:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=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 4Ar0F0u7bEpC for ; Tue, 17 Nov 2020 09:59:26 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 74AFF3A101A for ; Tue, 17 Nov 2020 09:59:25 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id l11so19281412lfg.0 for ; Tue, 17 Nov 2020 09:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fWTdSeHOY4P+NSCibGlSoZBc1jdb+hRnbUbcfNoUsQw=; b=NDO4HH16Lo/39Z+aJGCQYaiv4k5ii+4aeDqv9TDVmbk5f3brMYrIPKeuwZhtGtBUSs HC0IQFSrj4F0etlFm89xRZwFK7cC4VGDeNi0Q2zXqU99y8L6+VHAxeAgHSgOAd0bIFi/ /hzq33hmgYhHxdc3lpCNW9lW+z59zKxM/eFXF4iUQTuv708UWBI1rC9+3Akg7qkp5h8s onJ4jexia7JLyZOCxdEek/Moq0mzsKYAG2wAi3FDA/Dzz20sZftw/wufUdXbGQtr74qR X/TjM+NOH4cnB2UdXuVR/6fzIXwG5yYJ8ns8TXXkaCtGb1Eni02lb22eYC8/GUAhnOJF 6jSw== 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=fWTdSeHOY4P+NSCibGlSoZBc1jdb+hRnbUbcfNoUsQw=; b=GuKZ6ojuOeYOHjB3DebWYx1fwNDTj4KJpH+LkIxnByx8eKtVuYme7RJUukQIlkC+8N gDsUvcScXCSEM9uWZeb6/UG21aQIKm8/mFHChBF6Aor/T6RHZ6dl06lAPtLyDQTfCJGB so+ZBXQFGqwOaHTsl1j9b8OYzex7A22RE0w9WfPaQnlougibrCcPmTx2g+Tu3DD8xsuS NoapJzsYW+ypHHjnMdVKCC2ffA0fxhKHyFBdcwpqKKytRxGn+VwxcmxjmI+84tJU3Eof ocxpnuj5vbrdzWL9oLZCAif2J55me75I4nkQIK53Wdkv/GpkDw8md4rem0NUGDu7noiR 4hXA== X-Gm-Message-State: AOAM530KWxQudxSVnnVoKWcCIaBMZmoeOVet5JoLntARQObCrumqTZdl GiFijlavDaIWHl1hcYPsaH9yCxfKaRkUV56y6mo= X-Google-Smtp-Source: ABdhPJyKzS3bCTsEYdB5/WkxvqIXimpFo/lOFJc/2n+0q+UdFBjQicVCeSlthO5C37ISitcFRNwMoPtKaFNULkc5CV0= X-Received: by 2002:a05:6512:6c5:: with SMTP id u5mr2309170lff.316.1605635963306; Tue, 17 Nov 2020 09:59:23 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Dick Hardt Date: Tue, 17 Nov 2020 09:58:46 -0800 Message-ID: To: Tom Jones Cc: Justin Richer , Fabien Imbault , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000003b46a305b45141bd" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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: Tue, 17 Nov 2020 17:59:29 -0000 --0000000000003b46a305b45141bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom I watched your video (I watched at 2X speed) Looks like the employment website app that is using localhost:8765 to communicate with the wallet. Am I correct? /Dick =E1=90=A7 On Tue, Nov 17, 2020 at 9:46 AM Tom Jones wrote: > Well, here's a demo. Note that in this case the AS is not online all of > the time, so it is really implicit flow and the OIDC id-token comes from > the siop device directly. > (whether this is front-channel or back channel is no longer an interestin= g > question.) > Now if an always-on AS is required, that is possible, but probably beyond > the scope of this effort and would require something like an > agent-in-the-sky (with diamonds). > here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 > > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: > >> Ultimately, in most situations like these in the real world, the hurdle >> isn=E2=80=99t technical compatibility so much as it is trust compatibili= ty. The RP >> (client) needs to have some incentive to trust the assertions and identi= ty >> information that=E2=80=99s coming from the AS. The same is true for an R= S trusting >> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to d= o that (which SSI >> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, >> because it=E2=80=99s a hard question). >> >> Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on >> device=E2=80=9D element. We=E2=80=99ve got the start of it more than OAu= th2/OIDC have by >> allowing the bootstrap of the process from a starting call: the interact= ion >> and continuation URIs handed back by the AS don=E2=80=99t need to be the= same URIs >> that the client starts with, so just like SIOP the process can start in >> HTTP and potentially move to other communication channels. A major >> difference is that we aren=E2=80=99t dependent on the assumption that th= e user will >> always be in a browser at some stage, and so the whole raft of >> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That sai= d, we=E2=80=99ve >> got an opportunity to more explicitly open up alternative communication >> channels here, and that=E2=80=99s something I=E2=80=99d like to see engi= neered, even if >> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal a= s to how that would >> work over specific protocols, starting with what we=E2=80=99ve got today= . >> >> =E2=80=94 Justin >> >> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >> wrote: >> >> Hi Denis, hi Francis, >> >> At some point integration with SSI (on the authentication side) will >> probably occur, including amongst other possibilities SIOP (since they w= ork >> with OpenID a part of the work will probably be made easier). >> >> That being said, Denis is right. It's not an AS. Technically it's >> entirely possible to rely on a decentralized wallet (for instance on you= r >> phone) and a centralized AS. I know of a few studies on how to decentral= ize >> the AS itself (for instance >> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >> Maybe it exists, but I'm still looking for real scenarios (or even >> architectures) where an AS is deployed directly on a phone, and under th= e >> sole authority of the RO, while being compatible with the rest of the >> world. >> >> Cheers, >> Fabien >> >> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >> >>> Hello Francis, >>> >>> See two comments in line. >>> >>> >>> B) Current Document >>> >>> Roles description shall not hold any assumption on the physical >>> structure of the party fulfilling the roles. >>> [FI] not sure what you mean >>> >>> [FP] for example, we assume the AS is a server! In most SSI based use >>> cases, the AS will be running on the user device. See SIOP ( >>> https://identity.foundation/did-siop/). >>> >>> I browsed through the two drafts, i.e. : >>> >>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>> model, and representations W3C Working Draft 08 November 2020 >>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >>> Group Draft >>> >>> At no place within these two documents, it is possible to imagine that >>> "the AS will be running on the user device". >>> >>> From section 3 of the DIF Working Group Draft: >>> >>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >>> SIOP will not return an access token to the RP". >>> >>> An Identity Wallet is not an AS. >>> >>> >>> Roles: >>> -> grant endpoint of the AS: Why is this a post request? This eliminate= s >>> the chance of having user device hosted AS (no server). >>> [FI] what would you propose instead? >>> Would also be interested to understand better the deployment model when >>> there is no server. That's something that was discussed several times b= ut >>> I'm still missing the underlying architecture and use case. >>> >>> [FP] See above (SIOP). There will be a lot of identity wallets operate= d >>> on end user device. >>> >>> See the above comment. Please, do not confuse an Identity Wallet with a= n >>> Authentication Server (AS). >>> >>> Denis >>> >>> >>> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >>> request or the access to a resource? >>> [FI] yes, we should make the wording clearer >>> >>> Missing Section Interactions: >>> --> This section shall introduce the notion of interaction before we >>> start listing interaction types. >>> [FI] yes >>> >>> Interaction Types: >>> --> I prefer a classification with Redirect, Decoupled and Embedded is. >>> In the draft, we have one redirect and 2 decouple interactions and noth= ing >>> else. >>> [FI] this should be handled as a specific discussion item. As a >>> reminder, how would you define embedded? >>> >>> In practice there's at least these modes: >>> - redirect and redirect back >>> - redirect to different browser or device >>> - user code >>> - CIBA >>> >>> [FP] This classification is limited. >>> >>> - Redirect: same device, same or different user agents (browser, >>> mobile app, desktop app, ...) >>> - Decoupled: different devices >>> - Embedded : RC carries RO authorization to AS >>> >>> >>> >>> Resource Access Request vs. Resource Request >>> --> Both are mixed up. No clarification of the context of each section. >>> [FI] could you clarify what you'd expect. Btw on this topic, there's a >>> more general discussion on whether we should make a distinction or not. >>> >>> =E2=80=8B[FP]: Here: >>> >>> - Resource Access Request: Requesting Access to a resource. Response >>> is an access token (or any type of grant) >>> - Resource Request: Request the resource. Response is the resource >>> (or a corresponding execution) >>> >>> >>> Token Content Negotiation >>> --> Not expressed as such. This is central to GNAP and not represented >>> enough in the document. >>> [FI] right. This should be a specific discussion item. >>> >>> Requesting "User" Information >>> we identify two types of users: RQ and RO. It will be better not to >>> refer to a user in this draft, but either to a RQ or an RO. >>> [FI] yes that would avoid potential misunderstandings. Although in the >>> end, people will translate RQ into user or end-user most of the time. C= f in >>> definition, currently we have Requesting Party (RQ, aka "user") >>> >>> >>> Interaction Again >>> -> For each interaction type, we will have to describe the protocol flo= w >>> and the nature and behavior of involved Roles (Parties), Elements, Requ= ests. >>> [FI] yes >>> >>> >>> [FP] Will these and into tickets? >>> >>> Best regards. >>> /Francis >>> >>> >>> >>> -- >>> 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 > --0000000000003b46a305b45141bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom

I watched your video (I watched = at 2X speed)

Looks like the employment website app= that is using localhost:8765 to communicate with the wallet. Am I correct?=

/Dick=C2=A0
3D""=E1=90=A7<= /div>
O= n Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here&#= 39;s a demo. Note that in this case the AS is not online all of the time, s= o it is really implicit flow and the OIDC id-token comes from the siop devi= ce directly.
(whether this is front-channel or back channel is no longe= r an interesting question.)
Now if an always-on AS is required, tha= t is possible, but probably beyond the scope of this effort and would requi= re something like an agent-in-the-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2=A0=C2=A0= =C2=A0https://youtu.be/Tq4hw7X5SW0<= /span>
Pea= ce ..tom


On Tue, Nov 17, 2020 at 9:2= 0 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real = world, the hurdle isn=E2=80=99t technical compatibility so much as it is tr= ust compatibility. The RP (client) needs to have some incentive to trust th= e assertions and identity information that=E2=80=99s coming from the AS. Th= e same is true for an RS trusting tokens from the AS. The hard question is = less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but more =E2=80= =9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very well, bec= ause it=E2=80=99s a hard question).

Still: it=E2=80=99s = definitely a question about how to support this =E2=80=9CAS on device=E2=80= =9D element. We=E2=80=99ve got the start of it more than OAuth2/OIDC have b= y allowing the bootstrap of the process from a starting call: the interacti= on and continuation URIs handed back by the AS don=E2=80=99t need to be the= same URIs that the client starts with, so just like SIOP the process can s= tart in HTTP and potentially move to other communication channels. A major = difference is that we aren=E2=80=99t dependent on the assumption that the u= ser will always be in a browser at some stage, and so the whole raft of fro= nt-channel messages that SIOP relies on doesn=E2=80=99t fly. That said, we= =E2=80=99ve got an opportunity to more explicitly open up alternative commu= nication channels here, and that=E2=80=99s something I=E2=80=99d like to se= e engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a = concrete proposal as to how that would work over specific protocols, starti= ng with what we=E2=80=99ve got today.=C2=A0

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

On Nov 17, 2020= , at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

=
Hi Denis, hi Francis,=C2=A0

At some poi= nt integration with SSI (on the authentication side) will probably occur, i= ncluding amongst other possibilities SIOP (since they work with OpenID a pa= rt of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it's= entirely possible to rely on a decentralized wallet (for instance on your = phone) and a centralized AS. I know of a few studies on how to decentralize= the AS itself (for instance=C2=A0https://tools.ietf.o= rg/html/draft-hardjono-oauth-decentralized-02).
Maybe it exis= ts, but I'm still looking for real scenarios (or even architectures) wh= ere an AS is deployed directly on a phone, and under the sole authority of = the RO, while being compatible with the rest of the world.=C2=A0
=
Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 P= M Denis <denis.i= etf@free.fr> wrote:
=20 =20 =20
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
=C2=A0[FP] for example, we assume the AS is a server! In mo= st SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagi= ne that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP"= .

An Identity Wallet is not an AS.


Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
=C2=A0[FP] See above (SIOP). There will be a lot of identit= y wallets operated on end user device.

See the above comment. Please, do not confuse an Identi= ty Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes=C2= =A0

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code=
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could yo= u clarify what you'd expect.=C2=A0 Btw on this topic, there's a more general discussion on whether we should make a distinction or not.=C2=A0
=E2=80=8B[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a specific discussion item.=C2=A0=

Requesting "User&quo= t; Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user=C2=A0or end-user most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes=C2= =A0=C2=A0

[FP] Will these and into tickets?

Best regards.
/Francis



--
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
--0000000000003b46a305b45141bd-- From nobody Tue Nov 17 10:06: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 6B1513A12EC for ; Tue, 17 Nov 2020 10:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTTPS_HTTP_MISMATCH=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=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 d4tUlFplE5HT for ; Tue, 17 Nov 2020 10:06:11 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 C66AE3A14E6 for ; Tue, 17 Nov 2020 10:06:11 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id l36so20333822ota.4 for ; Tue, 17 Nov 2020 10:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7qgVXy61hFxtQI7WO0d7xrkFzSWFBsq1DgFqxZJP5Xg=; b=HbR5+oWiTF2tFp1pMolbAhEVF38mo5YdKmhggxJ8cZBZomarFB7/DFkK1s4GYwy67f OVGSm1vBISnnGrcWHO1w9FXDC2IiGOAnBOQ0KAx/Nd/Jvz5TCIwg2YPHyE/zHuoD99IL M4bgAsHoEF4P+q7qJKqn/NR5MAYNylzvbqC/J73bBircHYHkknzdhGe7I5MiHO+0VnkG DhqLfLGrThj91ZfwN21VDVFwahYSeOGHC9G+VnX0WzZe/F6dWr5vyuu0rJPzceG4LkWA CgmEuKO/iJUmm8YWFoVzwAb/WIPBdktFo9oYaEb0MIgnrmVZ3PhQxc/90bw40jHwEQgM Uw9A== 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=7qgVXy61hFxtQI7WO0d7xrkFzSWFBsq1DgFqxZJP5Xg=; b=GJj3J5BfCETSGyWKqUfsZLq6JCYTiLQljgj/x1XQQGjvEKusD6WCpV4U9oBSP23Wpf BktVEU8rsd1rLeIT1fOna6YoOson7QmeB0x10NJdxr5sD9Z52ZxMQXab7vS+n1Tka7QJ +Juo6xvLsxbMo3+jY/8Wz0gZ2t5WRZtGMW0RryxdGlbeQsZoQQarpekBHJO77w6i3TYK K7xKDmCD7uFh+0xkHqjYM40E1SRhkY2DTB8TZv2vEszDVoLbKocSdH+IMRoSvWA2wg6O bQdaXVRYFLkJr7p5A1C769IjJ7YnoOYwnn+lZ6fnlISCsoLzOPMUCuWLb4keOznVMsVB kTNA== X-Gm-Message-State: AOAM533zaHdieXGLd80X8/IVMbG7NMDoe446Fd16J/cwgaqhDcULT/t5 MpCknuNwfaPfKlbkzrxKoLvmR7nQhvvtBiCE3OE= X-Google-Smtp-Source: ABdhPJwMK36eqCL3un1k8a+pq3ytp5UTh+F3zRwzUYfWwXl9einsOEIigqSOaT7DvTPkyvzKBEoXTehXi3V6AiFlBAw= X-Received: by 2002:a05:6830:1af7:: with SMTP id c23mr3722923otd.358.1605636370893; Tue, 17 Nov 2020 10:06:10 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Tom Jones Date: Tue, 17 Nov 2020 10:05:58 -0800 Message-ID: To: Dick Hardt Cc: Justin Richer , Fabien Imbault , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000868ee805b4515980" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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: Tue, 17 Nov 2020 18:06:14 -0000 --000000000000868ee805b4515980 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You are - that is not standard which is opeind:// This is the one step that still needs to be optimized for SIOP to have good UX. Peace ..tom On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote: > Hi Tom > > I watched your video (I watched at 2X speed) > > Looks like the employment website app that is using localhost:8765 to > communicate with the wallet. Am I correct? > > /Dick > =E1=90=A7 > > On Tue, Nov 17, 2020 at 9:46 AM Tom Jones > wrote: > >> Well, here's a demo. Note that in this case the AS is not online all of >> the time, so it is really implicit flow and the OIDC id-token comes from >> the siop device directly. >> (whether this is front-channel or back channel is no longer an >> interesting question.) >> Now if an always-on AS is required, that is possible, but probably beyon= d >> the scope of this effort and would require something like an >> agent-in-the-sky (with diamonds). >> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >> >> Peace ..tom >> >> >> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: >> >>> Ultimately, in most situations like these in the real world, the hurdle >>> isn=E2=80=99t technical compatibility so much as it is trust compatibil= ity. The RP >>> (client) needs to have some incentive to trust the assertions and ident= ity >>> information that=E2=80=99s coming from the AS. The same is true for an = RS trusting >>> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to = do that (which SSI >>> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, >>> because it=E2=80=99s a hard question). >>> >>> Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on >>> device=E2=80=9D element. We=E2=80=99ve got the start of it more than OA= uth2/OIDC have by >>> allowing the bootstrap of the process from a starting call: the interac= tion >>> and continuation URIs handed back by the AS don=E2=80=99t need to be th= e same URIs >>> that the client starts with, so just like SIOP the process can start in >>> HTTP and potentially move to other communication channels. A major >>> difference is that we aren=E2=80=99t dependent on the assumption that t= he user will >>> always be in a browser at some stage, and so the whole raft of >>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That sa= id, we=E2=80=99ve >>> got an opportunity to more explicitly open up alternative communication >>> channels here, and that=E2=80=99s something I=E2=80=99d like to see eng= ineered, even if >>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal = as to how that would >>> work over specific protocols, starting with what we=E2=80=99ve got toda= y. >>> >>> =E2=80=94 Justin >>> >>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >>> wrote: >>> >>> Hi Denis, hi Francis, >>> >>> At some point integration with SSI (on the authentication side) will >>> probably occur, including amongst other possibilities SIOP (since they = work >>> with OpenID a part of the work will probably be made easier). >>> >>> That being said, Denis is right. It's not an AS. Technically it's >>> entirely possible to rely on a decentralized wallet (for instance on yo= ur >>> phone) and a centralized AS. I know of a few studies on how to decentra= lize >>> the AS itself (for instance >>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >>> Maybe it exists, but I'm still looking for real scenarios (or even >>> architectures) where an AS is deployed directly on a phone, and under t= he >>> sole authority of the RO, while being compatible with the rest of the >>> world. >>> >>> Cheers, >>> Fabien >>> >>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>> >>>> Hello Francis, >>>> >>>> See two comments in line. >>>> >>>> >>>> B) Current Document >>>> >>>> Roles description shall not hold any assumption on the physical >>>> structure of the party fulfilling the roles. >>>> [FI] not sure what you mean >>>> >>>> [FP] for example, we assume the AS is a server! In most SSI based use >>>> cases, the AS will be running on the user device. See SIOP ( >>>> https://identity.foundation/did-siop/). >>>> >>>> I browsed through the two drafts, i.e. : >>>> >>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>>> model, and representations W3C Working Draft 08 November 2020 >>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >>>> Group Draft >>>> >>>> At no place within these two documents, it is possible to imagine that >>>> "the AS will be running on the user device". >>>> >>>> From section 3 of the DIF Working Group Draft: >>>> >>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >>>> SIOP will not return an access token to the RP". >>>> >>>> An Identity Wallet is not an AS. >>>> >>>> >>>> Roles: >>>> -> grant endpoint of the AS: Why is this a post request? This >>>> eliminates the chance of having user device hosted AS (no server). >>>> [FI] what would you propose instead? >>>> Would also be interested to understand better the deployment model whe= n >>>> there is no server. That's something that was discussed several times = but >>>> I'm still missing the underlying architecture and use case. >>>> >>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>> operated on end user device. >>>> >>>> See the above comment. Please, do not confuse an Identity Wallet with >>>> an Authentication Server (AS). >>>> >>>> Denis >>>> >>>> >>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >>>> request or the access to a resource? >>>> [FI] yes, we should make the wording clearer >>>> >>>> Missing Section Interactions: >>>> --> This section shall introduce the notion of interaction before we >>>> start listing interaction types. >>>> [FI] yes >>>> >>>> Interaction Types: >>>> --> I prefer a classification with Redirect, Decoupled and Embedded is= . >>>> In the draft, we have one redirect and 2 decouple interactions and not= hing >>>> else. >>>> [FI] this should be handled as a specific discussion item. As a >>>> reminder, how would you define embedded? >>>> >>>> In practice there's at least these modes: >>>> - redirect and redirect back >>>> - redirect to different browser or device >>>> - user code >>>> - CIBA >>>> >>>> [FP] This classification is limited. >>>> >>>> - Redirect: same device, same or different user agents (browser, >>>> mobile app, desktop app, ...) >>>> - Decoupled: different devices >>>> - Embedded : RC carries RO authorization to AS >>>> >>>> >>>> >>>> Resource Access Request vs. Resource Request >>>> --> Both are mixed up. No clarification of the context of each section= . >>>> [FI] could you clarify what you'd expect. Btw on this topic, there's = a >>>> more general discussion on whether we should make a distinction or not= . >>>> >>>> =E2=80=8B[FP]: Here: >>>> >>>> - Resource Access Request: Requesting Access to a resource. >>>> Response is an access token (or any type of grant) >>>> - Resource Request: Request the resource. Response is the resource >>>> (or a corresponding execution) >>>> >>>> >>>> Token Content Negotiation >>>> --> Not expressed as such. This is central to GNAP and not represented >>>> enough in the document. >>>> [FI] right. This should be a specific discussion item. >>>> >>>> Requesting "User" Information >>>> we identify two types of users: RQ and RO. It will be better not to >>>> refer to a user in this draft, but either to a RQ or an RO. >>>> [FI] yes that would avoid potential misunderstandings. Although in the >>>> end, people will translate RQ into user or end-user most of the time. = Cf in >>>> definition, currently we have Requesting Party (RQ, aka "user") >>>> >>>> >>>> Interaction Again >>>> -> For each interaction type, we will have to describe the protocol >>>> flow and the nature and behavior of involved Roles (Parties), Elements= , >>>> Requests. >>>> [FI] yes >>>> >>>> >>>> [FP] Will these and into tickets? >>>> >>>> Best regards. >>>> /Francis >>>> >>>> >>>> >>>> -- >>>> 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 >> > --000000000000868ee805b4515980 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to ha= ve good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
= Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using lo= calhost:8765 to communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov = 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well,= here's a demo. Note that in this case the AS is not online all of the = time, so it is really implicit flow and the OIDC id-token comes from the si= op device directly.
(whether this is front-channel or back channel is n= o longer an interesting question.)
Now if an always-on AS is requir= ed, that is possible, but probably beyond the scope of this effort and woul= d require something like an agent-in-the-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2=A0= =C2=A0=C2=A0https://youtu.be/Tq4hw7= X5SW0
Peace ..tom


On Tue, Nov 17, 2020= at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in th= e real world, the hurdle isn=E2=80=99t technical compatibility so much as i= t is trust compatibility. The RP (client) needs to have some incentive to t= rust the assertions and identity information that=E2=80=99s coming from the= AS. The same is true for an RS trusting tokens from the AS. The hard quest= ion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but more = =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very wel= l, because it=E2=80=99s a hard question).

Still: it=E2= =80=99s definitely a question about how to support this =E2=80=9CAS on devi= ce=E2=80=9D element. We=E2=80=99ve got the start of it more than OAuth2/OID= C have by allowing the bootstrap of the process from a starting call: the i= nteraction and continuation URIs handed back by the AS don=E2=80=99t need t= o be the same URIs that the client starts with, so just like SIOP the proce= ss can start in HTTP and potentially move to other communication channels. = A major difference is that we aren=E2=80=99t dependent on the assumption th= at the user will always be in a browser at some stage, and so the whole raf= t of front-channel messages that SIOP relies on doesn=E2=80=99t fly. That s= aid, we=E2=80=99ve got an opportunity to more explicitly open up alternativ= e communication channels here, and that=E2=80=99s something I=E2=80=99d lik= e to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to= see a concrete proposal as to how that would work over specific protocols,= starting with what we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 1= 7, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Denis, hi Francis,=C2=A0

At s= ome point integration with SSI (on the authentication side) will probably o= ccur, including amongst other possibilities SIOP (since they work with Open= ID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically i= t's entirely possible to rely on a decentralized wallet (for instance o= n your phone) and a centralized AS. I know of a few studies on how to decen= tralize the AS itself (for instance=C2=A0https://tools= .ietf.org/html/draft-hardjono-oauth-decentralized-02).
Maybe = it exists, but I'm still looking for real scenarios (or even architectu= res) where an AS is deployed directly on a phone, and under the sole author= ity of the RO, while being compatible with the rest of the world.=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at= 5:45 PM Denis <= denis.ietf@free.fr> wrote:
=20 =20 =20
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
=C2=A0[FP] for example, we assume the AS is a server! In mo= st SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagi= ne that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP"= .

An Identity Wallet is not an AS.


Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
=C2=A0[FP] See above (SIOP). There will be a lot of identit= y wallets operated on end user device.

See the above comment. Please, do not confuse an Identi= ty Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes=C2= =A0

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code=
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could yo= u clarify what you'd expect.=C2=A0 Btw on this topic, there's a more general discussion on whether we should make a distinction or not.=C2=A0
=E2=80=8B[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a specific discussion item.=C2=A0=

Requesting "User&quo= t; Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user=C2=A0or end-user most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes=C2= =A0=C2=A0

[FP] Will these and into tickets?

Best regards.
/Francis



--
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
--000000000000868ee805b4515980-- From nobody Tue Nov 17 10:07: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 228653A14FE for ; Tue, 17 Nov 2020 10:07:50 -0800 (PST) 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 b1iNYyFQL-hU for ; Tue, 17 Nov 2020 10:07:47 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4033A14EF for ; Tue, 17 Nov 2020 10:07:46 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id s9so25280562ljo.11 for ; Tue, 17 Nov 2020 10:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hCutSrj636+ceNdXJfe2wfzXLSzPqJQGBVqQZMlImKE=; b=M8e1UjOI396chqdj0YlEVN1wWl74uzDHsfh3j2hOQhxKNBCjNdQk4LNvrxphM9i0Xl eH3LZfjDKOrgiV8475T0MRlaB+LLeaw9SrCRhHZS72BeKHK7feTDSn4LxHWII9vLTuUk ysG6G36xwxQBImedmKbOr171KgfbdWYgQytx6u0W9eLWviuqeHtC/0S9sn9M0Fya42ui 8IaItGHziitvkliFviicsAzRW6okjy+bnCo2bectCLQvLLx5VCbnc4L1BGN++4i+wMYp +r7Ykho3ssA8u54mmGGBceRSwILWySyNWRbc/dv4dFUhi4Haycnk6JhTuxbPhsVHARUt n3vg== 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=hCutSrj636+ceNdXJfe2wfzXLSzPqJQGBVqQZMlImKE=; b=XGGHjqpdq4UDcn8E4IRbVCOWTxkGjB/FNEZ1W3WT28vppEqfIO/AH1vWnz3q2EJvqe JJ0Q8c7ELLEd0Da9oiv+99NOrPCGnXx0uPS/45V11h6vITdpAX/vWVIxFEBpdFCSr4Gd l+sYFXUGG5je8A7DqyDD2JJydwJfNCVrykm0emEvRALItFyxicaeLa3MRGibcRY7Rycg rutxxzKHO0465+BJ8l34JXz9NBY/6EfLr5uAwb+CZ58sYvCy01pExQ5UF5AynQrZB3si EDdEYNMLH+RXbZRA8T0Wu+S5aFLVKbOKftZPNDGPD4yvIn5hnKZ/BKC3BwTf4TiTYbgS PVKQ== X-Gm-Message-State: AOAM53067yp+RlcgOBbIcOubVlryEtZ7Rdzpqi3M0SHrKoAgDxhDeHDZ pganUzAMNRNpAaJZjKOSmc6ZPxph8lhQKpdX54k= X-Google-Smtp-Source: ABdhPJxTmOmcA4esLTrWJH0aqXGbOxADUmUooCwBp8Cm1SJecE1NuRBKIpYRS0DgdTl7etAQvRMW4oVXsZdQT9caX8s= X-Received: by 2002:a2e:9b13:: with SMTP id u19mr2167010lji.437.1605636464937; Tue, 17 Nov 2020 10:07:44 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> From: Dick Hardt Date: Tue, 17 Nov 2020 10:07:07 -0800 Message-ID: To: Justin Richer Cc: Fabien Imbault , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000021904005b4515f56" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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: Tue, 17 Nov 2020 18:07:50 -0000 --00000000000021904005b4515f56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin: there is no assumption in OIDC or OAuth that the user is in a web browser. There is an assumption that the client can load a URL -- but the OS can load the URL and launch an app -- a common practice now. Lots of examples of app to app flows on mobile today doing OAuth. I don't know of any way for independent mobile apps on iOS to communicate other than a deep links -- which is effectively an HTTP redirect. Do you? =E1=90=A7 On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: > Ultimately, in most situations like these in the real world, the hurdle > isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP > (client) needs to have some incentive to trust the assertions and identit= y > information that=E2=80=99s coming from the AS. The same is true for an RS= trusting > tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to do= that (which SSI > answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, > because it=E2=80=99s a hard question). > > Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on device=E2=80=9D > element. We=E2=80=99ve got the start of it more than OAuth2/OIDC have by = allowing > the bootstrap of the process from a starting call: the interaction and > continuation URIs handed back by the AS don=E2=80=99t need to be the same= URIs that > the client starts with, so just like SIOP the process can start in HTTP a= nd > potentially move to other communication channels. A major difference is > that we aren=E2=80=99t dependent on the assumption that the user will alw= ays be in > a browser at some stage, and so the whole raft of front-channel messages > that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an = opportunity to > more explicitly open up alternative communication channels here, and that= =E2=80=99s > something I=E2=80=99d like to see engineered, even if it=E2=80=99s an ext= ension. I=E2=80=99d love > to see a concrete proposal as to how that would work over specific > protocols, starting with what we=E2=80=99ve got today. > > =E2=80=94 Justin > > On Nov 17, 2020, at 12:03 PM, Fabien Imbault > wrote: > > Hi Denis, hi Francis, > > At some point integration with SSI (on the authentication side) will > probably occur, including amongst other possibilities SIOP (since they wo= rk > with OpenID a part of the work will probably be made easier). > > That being said, Denis is right. It's not an AS. Technically it's entirel= y > possible to rely on a decentralized wallet (for instance on your phone) a= nd > a centralized AS. I know of a few studies on how to decentralize the AS > itself (for instance > https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). > Maybe it exists, but I'm still looking for real scenarios (or even > architectures) where an AS is deployed directly on a phone, and under the > sole authority of the RO, while being compatible with the rest of the > world. > > Cheers, > Fabien > > On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: > >> Hello Francis, >> >> See two comments in line. >> >> >> B) Current Document >> >> Roles description shall not hold any assumption on the physical structur= e >> of the party fulfilling the roles. >> [FI] not sure what you mean >> >> [FP] for example, we assume the AS is a server! In most SSI based use >> cases, the AS will be running on the user device. See SIOP ( >> https://identity.foundation/did-siop/). >> >> I browsed through the two drafts, i.e. : >> >> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >> model, and representations W3C Working Draft 08 November 2020 >> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >> Group Draft >> >> At no place within these two documents, it is possible to imagine that >> "the AS will be running on the user device". >> >> From section 3 of the DIF Working Group Draft: >> >> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >> SIOP will not return an access token to the RP". >> >> An Identity Wallet is not an AS. >> >> >> Roles: >> -> grant endpoint of the AS: Why is this a post request? This eliminates >> the chance of having user device hosted AS (no server). >> [FI] what would you propose instead? >> Would also be interested to understand better the deployment model when >> there is no server. That's something that was discussed several times bu= t >> I'm still missing the underlying architecture and use case. >> >> [FP] See above (SIOP). There will be a lot of identity wallets operated >> on end user device. >> >> See the above comment. Please, do not confuse an Identity Wallet with an >> Authentication Server (AS). >> >> Denis >> >> >> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >> request or the access to a resource? >> [FI] yes, we should make the wording clearer >> >> Missing Section Interactions: >> --> This section shall introduce the notion of interaction before we >> start listing interaction types. >> [FI] yes >> >> Interaction Types: >> --> I prefer a classification with Redirect, Decoupled and Embedded is. >> In the draft, we have one redirect and 2 decouple interactions and nothi= ng >> else. >> [FI] this should be handled as a specific discussion item. As a reminder= , >> how would you define embedded? >> >> In practice there's at least these modes: >> - redirect and redirect back >> - redirect to different browser or device >> - user code >> - CIBA >> >> [FP] This classification is limited. >> >> - Redirect: same device, same or different user agents (browser, >> mobile app, desktop app, ...) >> - Decoupled: different devices >> - Embedded : RC carries RO authorization to AS >> >> >> >> Resource Access Request vs. Resource Request >> --> Both are mixed up. No clarification of the context of each section. >> [FI] could you clarify what you'd expect. Btw on this topic, there's a >> more general discussion on whether we should make a distinction or not. >> >> =E2=80=8B[FP]: Here: >> >> - Resource Access Request: Requesting Access to a resource. Response >> is an access token (or any type of grant) >> - Resource Request: Request the resource. Response is the resource >> (or a corresponding execution) >> >> >> Token Content Negotiation >> --> Not expressed as such. This is central to GNAP and not represented >> enough in the document. >> [FI] right. This should be a specific discussion item. >> >> Requesting "User" Information >> we identify two types of users: RQ and RO. It will be better not to refe= r >> to a user in this draft, but either to a RQ or an RO. >> [FI] yes that would avoid potential misunderstandings. Although in the >> end, people will translate RQ into user or end-user most of the time. Cf= in >> definition, currently we have Requesting Party (RQ, aka "user") >> >> >> Interaction Again >> -> For each interaction type, we will have to describe the protocol flow >> and the nature and behavior of involved Roles (Parties), Elements, Reque= sts. >> [FI] yes >> >> >> [FP] Will these and into tickets? >> >> Best regards. >> /Francis >> >> >> >> -- >> 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 > --00000000000021904005b4515f56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin: there is no assumption in OIDC or OAuth that the u= ser is in a web browser.=C2=A0

There is an assumption th= at the client can load a URL -- but the OS can load the URL and launch an a= pp -- a common practice now.

Lots of examples of a= pp to app flows on mobile today doing OAuth.

I don= 't know of any way for independent mobile apps on iOS to communicate ot= her than a deep links -- which is effectively=C2=A0an HTTP redirect. Do you= ?

3D""=E1=90=A7

On Tue, Nov 17, 2020= at 9:20 AM Justin Richer <jricher@mi= t.edu> wrote:
Ultimately, in most situatio= ns like these in the real world, the hurdle isn=E2=80=99t technical compati= bility so much as it is trust compatibility. The RP (client) needs to have = some incentive to trust the assertions and identity information that=E2=80= =99s coming from the AS. The same is true for an RS trusting tokens from th= e AS. The hard question is less =E2=80=9Chow=E2=80=9D to do that (which SSI= answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80= =99t answer very well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS d= on=E2=80=99t need to be the same URIs that the client starts with, so just = like SIOP the process can start in HTTP and potentially move to other commu= nication channels. A major difference is that we aren=E2=80=99t dependent o= n the assumption that the user will always be in a browser at some stage, a= nd so the whole raft of front-channel messages that SIOP relies on doesn=E2= =80=99t fly. That said, we=E2=80=99ve got an opportunity to more explicitly= open up alternative communication channels here, and that=E2=80=99s someth= ing I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. = I=E2=80=99d love to see a concrete proposal as to how that would work over = specific protocols, starting with what we=E2=80=99ve got today.=C2=A0
=

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com= > wrote:

Hi Denis, hi Francis,=C2=A0
=
At some point integration with SSI (on the authentication si= de) will probably occur, including amongst other possibilities SIOP (since = they work with OpenID a part of the work will probably be made easier).=C2= =A0

That being said, Denis is right. It's not = an AS. Technically it's entirely possible to rely on a decentralized wa= llet (for instance on your phone) and a centralized AS. I know of a few stu= dies on how to decentralize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02).


On = Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
=C2=A0[FP] for example, we assume the AS is a server! In mo= st SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagi= ne that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP"= .

An Identity Wallet is not an AS.


Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
=C2=A0[FP] See above (SIOP). There will be a lot of identit= y wallets operated on end user device.

See the above comment. Please, do not confuse an Identi= ty Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes=C2= =A0

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code=
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could yo= u clarify what you'd expect.=C2=A0 Btw on this topic, there's a more general discussion on whether we should make a distinction or not.=C2=A0
=E2=80=8B[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a specific discussion item.=C2=A0=

Requesting "User&quo= t; Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user=C2=A0or end-user most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes=C2= =A0=C2=A0

[FP] Will these and into tickets?

Best regards.
/Francis



--
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
--00000000000021904005b4515f56-- From nobody Tue Nov 17 10:29: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 DE2F63A13B9 for ; Tue, 17 Nov 2020 10:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTTPS_HTTP_MISMATCH=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=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 bs6VSo7UGuhh for ; Tue, 17 Nov 2020 10:29:03 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 C1A603A1518 for ; Tue, 17 Nov 2020 10:29:02 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id r9so31468508lfn.11 for ; Tue, 17 Nov 2020 10:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gHhpxAwu/mCSRsOoGIfHGgk7Xetwv+REqFaXroEM4aE=; b=dTi1VN15Ru1UbWSo2bkdstsr20/eOVbA0ppKFvZ/u64mz5Bk6POrTE6Oi9Xp91BqoJ xTMreWul5hXpOoezpFaMkrD7LLMxDKVt7zALY+Jm3KOGRdSvdGd0hqKc7ZgpTEi7996u p8WZbbWdcGjdNVdESYGho4x9tj8HIY3YBRCyLAnX9uwgghkIR/FmjXNMxXor6/OYTlc8 AiF1FIGN5GCzA0xsRyCFsLcE1/3dosOlGuHJ4u2/aVPWKwONzn2iZmCe8cSoC8sv7SIn Suhdsot9M5sjT9IxrdWgsj/eq8fyFAx6Cck+zsrN1Tx5aWwGGl33P9cPWxIdCkBQx+Yx r8+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=gHhpxAwu/mCSRsOoGIfHGgk7Xetwv+REqFaXroEM4aE=; b=LkM70NxE4mvk3BLjgNeJHGeWLbPhOrQ5xY5JF0lRxzyL0RlAMJ+7lKtgRJxuPK+iiz HxJ4ArW24p6b5IHXYdxUfsyRRKiNHRx03iDZ7Z0QXY3t7VKBvCxvwN2ICndUeJW9xyaQ YVQNzZ9hEPJGFGU7PyKLOcjS0YaSYy4sfmbTvUAbZBnAZTYj6BgWf4jNIuGGvAOn7BnF axDjRlWHaUBZiB9JMaJ3WseKSTqFqVcV2wV+ONgNfW4zasBSXUSjr1RHtJGqEN2k3wFQ KTVu1XPpywY3nt7h9IuxrdbTH5h4ky3tzkyj00vttMW6wGaHFZ5M5EbdF95mBv036UCV h+jg== X-Gm-Message-State: AOAM531SLYnLCZnZyx/+/96isjmfsPvOar8Cg9baGVk768DRthhYPNDl DBtFzjMt6CDIrTJlOR9hmPElSqDC2fKGv0zleU8= X-Google-Smtp-Source: ABdhPJwUvMsvC4P1Vq8I7xGdwKmMAzseQmA1KqFYCsWeIBrl1N3jxQmht39YbfL6PU9NrwKIUrc2LD3QMW4s+8IRdX8= X-Received: by 2002:a19:6e4c:: with SMTP id q12mr2073952lfk.162.1605637740504; Tue, 17 Nov 2020 10:29:00 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Dick Hardt Date: Tue, 17 Nov 2020 10:28:23 -0800 Message-ID: To: Tom Jones Cc: Justin Richer , Fabien Imbault , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000292bdb05b451ab06" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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: Tue, 17 Nov 2020 18:29:06 -0000 --000000000000292bdb05b451ab06 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Got it. So web apps invoke a openid: deep link and hope there is an app to handle the openid: scheme? ... and that it is the user's wallet rather than some malware that has registered openid: on the mobile device? A native app can attempt to open a deep link associated with an app, and will fail if the app is not there. If the app is there, it will be opened, so this can't be used to silently test if an app is present, but it does allow a native app to provide an alternative experience if an app is not present. I don't think this works with custom schemes ... and I don't know how it could work from a web app on the phone with the current Safari APIs. Apple warns against using custom schemes [1] ... but perhaps they can be convinced to make openid: a managed scheme similar to mailto:, tel:, sms:, facetime: ? [1] https://developer.apple.com/documentation/xcode/allowing_apps_and_websites_= to_link_to_your_content/defining_a_custom_url_scheme_for_your_app =E1=90=A7 On Tue, Nov 17, 2020 at 10:06 AM Tom Jones wrote: > You are - that is not standard which is opeind:// > This is the one step that still needs to be optimized for SIOP to have > good UX. > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote: > >> Hi Tom >> >> I watched your video (I watched at 2X speed) >> >> Looks like the employment website app that is using localhost:8765 to >> communicate with the wallet. Am I correct? >> >> /Dick >> =E1=90=A7 >> >> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones >> wrote: >> >>> Well, here's a demo. Note that in this case the AS is not online all of >>> the time, so it is really implicit flow and the OIDC id-token comes fro= m >>> the siop device directly. >>> (whether this is front-channel or back channel is no longer an >>> interesting question.) >>> Now if an always-on AS is required, that is possible, but probably >>> beyond the scope of this effort and would require something like an >>> agent-in-the-sky (with diamonds). >>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >>> >>> Peace ..tom >>> >>> >>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: >>> >>>> Ultimately, in most situations like these in the real world, the hurdl= e >>>> isn=E2=80=99t technical compatibility so much as it is trust compatibi= lity. The RP >>>> (client) needs to have some incentive to trust the assertions and iden= tity >>>> information that=E2=80=99s coming from the AS. The same is true for an= RS trusting >>>> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to= do that (which SSI >>>> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn= =E2=80=99t answer very well, >>>> because it=E2=80=99s a hard question). >>>> >>>> Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on >>>> device=E2=80=9D element. We=E2=80=99ve got the start of it more than O= Auth2/OIDC have by >>>> allowing the bootstrap of the process from a starting call: the intera= ction >>>> and continuation URIs handed back by the AS don=E2=80=99t need to be t= he same URIs >>>> that the client starts with, so just like SIOP the process can start i= n >>>> HTTP and potentially move to other communication channels. A major >>>> difference is that we aren=E2=80=99t dependent on the assumption that = the user will >>>> always be in a browser at some stage, and so the whole raft of >>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That s= aid, we=E2=80=99ve >>>> got an opportunity to more explicitly open up alternative communicatio= n >>>> channels here, and that=E2=80=99s something I=E2=80=99d like to see en= gineered, even if >>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal= as to how that would >>>> work over specific protocols, starting with what we=E2=80=99ve got tod= ay. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >>>> wrote: >>>> >>>> Hi Denis, hi Francis, >>>> >>>> At some point integration with SSI (on the authentication side) will >>>> probably occur, including amongst other possibilities SIOP (since they= work >>>> with OpenID a part of the work will probably be made easier). >>>> >>>> That being said, Denis is right. It's not an AS. Technically it's >>>> entirely possible to rely on a decentralized wallet (for instance on y= our >>>> phone) and a centralized AS. I know of a few studies on how to decentr= alize >>>> the AS itself (for instance >>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >>>> Maybe it exists, but I'm still looking for real scenarios (or even >>>> architectures) where an AS is deployed directly on a phone, and under = the >>>> sole authority of the RO, while being compatible with the rest of the >>>> world. >>>> >>>> Cheers, >>>> Fabien >>>> >>>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>>> >>>>> Hello Francis, >>>>> >>>>> See two comments in line. >>>>> >>>>> >>>>> B) Current Document >>>>> >>>>> Roles description shall not hold any assumption on the physical >>>>> structure of the party fulfilling the roles. >>>>> [FI] not sure what you mean >>>>> >>>>> [FP] for example, we assume the AS is a server! In most SSI based us= e >>>>> cases, the AS will be running on the user device. See SIOP ( >>>>> https://identity.foundation/did-siop/). >>>>> >>>>> I browsed through the two drafts, i.e. : >>>>> >>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>>>> model, and representations W3C Working Draft 08 November 2020 >>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>> Working Group Draft >>>>> >>>>> At no place within these two documents, it is possible to imagine tha= t >>>>> "the AS will be running on the user device". >>>>> >>>>> From section 3 of the DIF Working Group Draft: >>>>> >>>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], th= e >>>>> SIOP will not return an access token to the RP". >>>>> >>>>> An Identity Wallet is not an AS. >>>>> >>>>> >>>>> Roles: >>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>> eliminates the chance of having user device hosted AS (no server). >>>>> [FI] what would you propose instead? >>>>> Would also be interested to understand better the deployment model >>>>> when there is no server. That's something that was discussed several = times >>>>> but I'm still missing the underlying architecture and use case. >>>>> >>>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>>> operated on end user device. >>>>> >>>>> See the above comment. Please, do not confuse an Identity Wallet with >>>>> an Authentication Server (AS). >>>>> >>>>> Denis >>>>> >>>>> >>>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize th= e >>>>> request or the access to a resource? >>>>> [FI] yes, we should make the wording clearer >>>>> >>>>> Missing Section Interactions: >>>>> --> This section shall introduce the notion of interaction before we >>>>> start listing interaction types. >>>>> [FI] yes >>>>> >>>>> Interaction Types: >>>>> --> I prefer a classification with Redirect, Decoupled and Embedded >>>>> is. In the draft, we have one redirect and 2 decouple interactions an= d >>>>> nothing else. >>>>> [FI] this should be handled as a specific discussion item. As a >>>>> reminder, how would you define embedded? >>>>> >>>>> In practice there's at least these modes: >>>>> - redirect and redirect back >>>>> - redirect to different browser or device >>>>> - user code >>>>> - CIBA >>>>> >>>>> [FP] This classification is limited. >>>>> >>>>> - Redirect: same device, same or different user agents (browser, >>>>> mobile app, desktop app, ...) >>>>> - Decoupled: different devices >>>>> - Embedded : RC carries RO authorization to AS >>>>> >>>>> >>>>> >>>>> Resource Access Request vs. Resource Request >>>>> --> Both are mixed up. No clarification of the context of each sectio= n. >>>>> [FI] could you clarify what you'd expect. Btw on this topic, there's >>>>> a more general discussion on whether we should make a distinction or = not. >>>>> >>>>> =E2=80=8B[FP]: Here: >>>>> >>>>> - Resource Access Request: Requesting Access to a resource. >>>>> Response is an access token (or any type of grant) >>>>> - Resource Request: Request the resource. Response is the resource >>>>> (or a corresponding execution) >>>>> >>>>> >>>>> Token Content Negotiation >>>>> --> Not expressed as such. This is central to GNAP and not represente= d >>>>> enough in the document. >>>>> [FI] right. This should be a specific discussion item. >>>>> >>>>> Requesting "User" Information >>>>> we identify two types of users: RQ and RO. It will be better not to >>>>> refer to a user in this draft, but either to a RQ or an RO. >>>>> [FI] yes that would avoid potential misunderstandings. Although in th= e >>>>> end, people will translate RQ into user or end-user most of the time.= Cf in >>>>> definition, currently we have Requesting Party (RQ, aka "user") >>>>> >>>>> >>>>> Interaction Again >>>>> -> For each interaction type, we will have to describe the protocol >>>>> flow and the nature and behavior of involved Roles (Parties), Element= s, >>>>> Requests. >>>>> [FI] yes >>>>> >>>>> >>>>> [FP] Will these and into tickets? >>>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>> >> --000000000000292bdb05b451ab06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got it.=C2=A0

So web apps invoke a = openid: deep link and hope there is an app to handle the openid: scheme? ..= . and that it is the user's wallet rather than some malware that has re= gistered openid: on the mobile device?

A native ap= p can attempt to open a deep link associated with an app, and will fail if = the app is not there. If the app is there, it will be opened, so this can&#= 39;t be used to silently test if an app is present, but it does allow a nat= ive app to provide an alternative experience if an app is not present. I do= n't think this works with custom schemes ... and I don't know how i= t could work from a web app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but p= erhaps they can be convinced to make openid: a managed scheme similar to ma= ilto:, tel:, sms:, facetime: ?


3D""=E1=90=A7

On Tue, Nov 17, 2020= at 10:06 AM Tom Jones <= thomasclinganjones@gmail.com> wrote:
You are - that is not sta= ndard which is opeind://
This is the one step that still needs to= be optimized for SIOP to have good UX.
Peace ..tom

<= br>
On Tue,= Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom

=
I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to= communicate with the wallet. Am I correct?

/Dick= =C2=A0
<= img alt=3D"" style=3D"width: 0px; max-height: 0px; overflow: hidden;" src= =3D"https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%= 3D&type=3Dzerocontent&guid=3D11a62ce6-9b4a-4d5f-86c5-d2c114395aee">= =E1=90=A7

On Tue, Nov 17, 2020 at = 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, here's = a demo. Note that in this case the AS is not online all of the time, so it = is really implicit flow and the OIDC id-token comes from the siop device di= rectly.
(whether this is front-channel or back channel is no longer an = interesting question.)
Now if an always-on AS is required, that is = possible, but probably beyond the scope of this effort and would require so= mething like an agent-in-the-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2=A0=C2=A0=C2=A0<= /span>https://youtu.be/Tq4hw7X5SW0<= /a>
Peace ..to= m


On Tue, Nov 17, 2020 at 9:20 AM Ju= stin Richer <jriche= r@mit.edu> wrote:
Ultimately, in most situations like these in the real world= , the hurdle isn=E2=80=99t technical compatibility so much as it is trust c= ompatibility. The RP (client) needs to have some incentive to trust the ass= ertions and identity information that=E2=80=99s coming from the AS. The sam= e is true for an RS trusting tokens from the AS. The hard question is less = =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but more =E2=80=9Cwhy= =E2=80=9D to do that (which SSI doesn=E2=80=99t answer very well, because i= t=E2=80=99s a hard question).

Still: it=E2=80=99s defini= tely a question about how to support this =E2=80=9CAS on device=E2=80=9D el= ement. We=E2=80=99ve got the start of it more than OAuth2/OIDC have by allo= wing the bootstrap of the process from a starting call: the interaction and= continuation URIs handed back by the AS don=E2=80=99t need to be the same = URIs that the client starts with, so just like SIOP the process can start i= n HTTP and potentially move to other communication channels. A major differ= ence is that we aren=E2=80=99t dependent on the assumption that the user wi= ll always be in a browser at some stage, and so the whole raft of front-cha= nnel messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80= =99ve got an opportunity to more explicitly open up alternative communicati= on channels here, and that=E2=80=99s something I=E2=80=99d like to see engi= neered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concre= te proposal as to how that would work over specific protocols, starting wit= h what we=E2=80=99ve got today.=C2=A0

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

On Nov 17, 2020, at 1= 2:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point int= egration with SSI (on the authentication side) will probably occur, includi= ng amongst other possibilities SIOP (since they work with OpenID a part of = the work will probably be made easier).=C2=A0

That= being said, Denis is right. It's not an AS. Technically it's entir= ely possible to rely on a decentralized wallet (for instance on your phone)= and a centralized AS. I know of a few studies on how to decentralize the A= S itself (for instance=C2=A0https://tools.ietf.org/htm= l/draft-hardjono-oauth-decentralized-02).
Maybe it exists, bu= t I'm still looking for real scenarios (or even architectures) where an= AS is deployed directly on a phone, and under the sole authority of the RO= , while being compatible with the rest of the world.=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Deni= s <denis.ietf@fr= ee.fr> wrote:
=20 =20 =20
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
=C2=A0[FP] for example, we assume the AS is a server! In mo= st SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagi= ne that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP"= .

An Identity Wallet is not an AS.


Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
=C2=A0[FP] See above (SIOP). There will be a lot of identit= y wallets operated on end user device.

See the above comment. Please, do not confuse an Identi= ty Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes=C2= =A0

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code=
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could yo= u clarify what you'd expect.=C2=A0 Btw on this topic, there's a more general discussion on whether we should make a distinction or not.=C2=A0
=E2=80=8B[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a specific discussion item.=C2=A0=

Requesting "User&quo= t; Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user=C2=A0or end-user most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes=C2= =A0=C2=A0

[FP] Will these and into tickets?

Best regards.
/Francis



--
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
--000000000000292bdb05b451ab06-- From nobody Tue Nov 17 11:02: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 7630E3A1563 for ; Tue, 17 Nov 2020 11:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTTPS_HTTP_MISMATCH=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=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 tG7LMCPpGd9G for ; Tue, 17 Nov 2020 11:02:50 -0800 (PST) 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 485FB3A155A for ; Tue, 17 Nov 2020 11:02:50 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id y4so17795411edy.5 for ; Tue, 17 Nov 2020 11:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=W9XT98BJS/eVwQGCyd4oPxcfGBCovi+tN0wAwt1u9Y0=; b=FuKJ9PmypD1gIK3JFYS9z70R57WDhJVzxrOwKrgO+WC11pyvZgDc/3YoIlnPmuzd5g Q/UOKtt4qfsD7nqttTD3f5xYg7BgTWFD8ANHJS9RI9J7Ss11rTPSSTeIjGht61ZMumQu pu+zd2szILkCzhHG7HI9Y1Y5k+fr6kReApxJ0WFApMQzI8gcE+idRhRJk0QTtXSA2lpY 54cisuK7eQ5zp7eTQ+5If2l8c+h5AWuHboR3HhDWLOS5G2FSPN9Qn8GuahcIQMas/tid dGMjRCbB+tDCuWqYhyEk+jcQU+3Ee65AjPLkP0zt3VlKgv1j5cU3y+L7qDf+4CUfmUB9 gyfA== 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=W9XT98BJS/eVwQGCyd4oPxcfGBCovi+tN0wAwt1u9Y0=; b=l79CF9K1Dyg8V5mP6dNYOIUJYLvYkKBCK8Oyk3Zks2bHb7GmG90072Uzb+ZpGlOa5x NFST9do9OxZ5XH3PYsTUwq+Ruc3BFK5GOsdEGUwiDB/YexaVNtqQkWLnxE1w0FNHxY15 ZGB0pivQIQKJPKCvbAeCxmV2KNAWvviLMKvKosaKm7QTgNvGaI/p9GgjClwlN3dKT4Zq XnQJecSVQtESH+/xHjByt7QjNnRKSh2sb4QNC7WTwZ181uC+B/JTdbfUAuXr1uQeYL4W Pif88NMksLCWZTT4eyiXZ954WLDqSqOrEOlo/3UuFz3FmemzM2NLfTAvburtqisOBBcq SRgQ== X-Gm-Message-State: AOAM530cnVlvSCrOK4hpx6VCRxtzYLLb8K1QenEOeq/LYzjwjPnYQD8w pWE2FHQrmWj36GfGPG/e1GPJe4Yj+sf98k5J5Hs4oeRPR/s= X-Google-Smtp-Source: ABdhPJyl9iQh0S4AbXYMP8ZdOB0aBwJhn0E3Kk31kO11cFaA5mF9Kyk4ziY0O3vUKnQcPwXNtjfD1glUsAryEkZ3e5o= X-Received: by 2002:a50:f392:: with SMTP id g18mr22745168edm.140.1605639768529; Tue, 17 Nov 2020 11:02:48 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Dick Hardt Date: Tue, 17 Nov 2020 11:02:10 -0800 Message-ID: To: Tom Jones , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000000a607905b4522474" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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: Tue, 17 Nov 2020 19:02:54 -0000 --0000000000000a607905b4522474 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It would seem that the mobile OSes would need to support a new scheme "openid:" ... and provide a mechanism in both the mobile browser and mobile apps to detect if an "openid:" handler has been installed. =E1=90=A7 On Tue, Nov 17, 2020 at 10:32 AM Tom Jones wrote: > yes - this is the sticking point for siop - not sure how it will get > resolved. > Peace ..tom > > > On Tue, Nov 17, 2020 at 10:29 AM Dick Hardt wrote: > >> Got it. >> >> So web apps invoke a openid: deep link and hope there is an app to handl= e >> the openid: scheme? ... and that it is the user's wallet rather than som= e >> malware that has registered openid: on the mobile device? >> >> A native app can attempt to open a deep link associated with an app, and >> will fail if the app is not there. If the app is there, it will be opene= d, >> so this can't be used to silently test if an app is present, but it does >> allow a native app to provide an alternative experience if an app is not >> present. I don't think this works with custom schemes ... and I don't kn= ow >> how it could work from a web app on the phone with the current Safari AP= Is. >> >> Apple warns against using custom schemes [1] ... but perhaps they can be >> convinced to make openid: a managed scheme similar to mailto:, tel:, >> sms:, facetime: ? >> >> [1] >> https://developer.apple.com/documentation/xcode/allowing_apps_and_websit= es_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >> >> >> =E1=90=A7 >> >> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones >> wrote: >> >>> You are - that is not standard which is opeind:// >>> This is the one step that still needs to be optimized for SIOP to have >>> good UX. >>> Peace ..tom >>> >>> >>> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote= : >>> >>>> Hi Tom >>>> >>>> I watched your video (I watched at 2X speed) >>>> >>>> Looks like the employment website app that is using localhost:8765 to >>>> communicate with the wallet. Am I correct? >>>> >>>> /Dick >>>> =E1=90=A7 >>>> >>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones >>>> wrote: >>>> >>>>> Well, here's a demo. Note that in this case the AS is not online all >>>>> of the time, so it is really implicit flow and the OIDC id-token come= s from >>>>> the siop device directly. >>>>> (whether this is front-channel or back channel is no longer an >>>>> interesting question.) >>>>> Now if an always-on AS is required, that is possible, but probably >>>>> beyond the scope of this effort and would require something like an >>>>> agent-in-the-sky (with diamonds). >>>>> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >>>>> >>>>> Peace ..tom >>>>> >>>>> >>>>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote= : >>>>> >>>>>> Ultimately, in most situations like these in the real world, the >>>>>> hurdle isn=E2=80=99t technical compatibility so much as it is trust = compatibility. >>>>>> The RP (client) needs to have some incentive to trust the assertions= and >>>>>> identity information that=E2=80=99s coming from the AS. The same is = true for an RS >>>>>> trusting tokens from the AS. The hard question is less =E2=80=9Chow= =E2=80=9D to do that >>>>>> (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that (whic= h SSI doesn=E2=80=99t answer >>>>>> very well, because it=E2=80=99s a hard question). >>>>>> >>>>>> Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on >>>>>> device=E2=80=9D element. We=E2=80=99ve got the start of it more than= OAuth2/OIDC have by >>>>>> allowing the bootstrap of the process from a starting call: the inte= raction >>>>>> and continuation URIs handed back by the AS don=E2=80=99t need to be= the same URIs >>>>>> that the client starts with, so just like SIOP the process can start= in >>>>>> HTTP and potentially move to other communication channels. A major >>>>>> difference is that we aren=E2=80=99t dependent on the assumption tha= t the user will >>>>>> always be in a browser at some stage, and so the whole raft of >>>>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That= said, we=E2=80=99ve >>>>>> got an opportunity to more explicitly open up alternative communicat= ion >>>>>> channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if >>>>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete propos= al as to how that would >>>>>> work over specific protocols, starting with what we=E2=80=99ve got t= oday. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>> Hi Denis, hi Francis, >>>>>> >>>>>> At some point integration with SSI (on the authentication side) will >>>>>> probably occur, including amongst other possibilities SIOP (since th= ey work >>>>>> with OpenID a part of the work will probably be made easier). >>>>>> >>>>>> That being said, Denis is right. It's not an AS. Technically it's >>>>>> entirely possible to rely on a decentralized wallet (for instance on= your >>>>>> phone) and a centralized AS. I know of a few studies on how to decen= tralize >>>>>> the AS itself (for instance >>>>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >>>>>> Maybe it exists, but I'm still looking for real scenarios (or even >>>>>> architectures) where an AS is deployed directly on a phone, and unde= r the >>>>>> sole authority of the RO, while being compatible with the rest of th= e >>>>>> world. >>>>>> >>>>>> Cheers, >>>>>> Fabien >>>>>> >>>>>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>>>>> >>>>>>> Hello Francis, >>>>>>> >>>>>>> See two comments in line. >>>>>>> >>>>>>> >>>>>>> B) Current Document >>>>>>> >>>>>>> Roles description shall not hold any assumption on the physical >>>>>>> structure of the party fulfilling the roles. >>>>>>> [FI] not sure what you mean >>>>>>> >>>>>>> [FP] for example, we assume the AS is a server! In most SSI based >>>>>>> use cases, the AS will be running on the user device. See SIOP ( >>>>>>> https://identity.foundation/did-siop/). >>>>>>> >>>>>>> I browsed through the two drafts, i.e. : >>>>>>> >>>>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>>>>>> model, and representations W3C Working Draft 08 November 2020 >>>>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>>>> Working Group Draft >>>>>>> >>>>>>> At no place within these two documents, it is possible to imagine >>>>>>> that "the AS will be running on the user device". >>>>>>> >>>>>>> From section 3 of the DIF Working Group Draft: >>>>>>> >>>>>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], >>>>>>> the SIOP will not return an access token to the RP". >>>>>>> >>>>>>> An Identity Wallet is not an AS. >>>>>>> >>>>>>> >>>>>>> Roles: >>>>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>>>> eliminates the chance of having user device hosted AS (no server). >>>>>>> [FI] what would you propose instead? >>>>>>> Would also be interested to understand better the deployment model >>>>>>> when there is no server. That's something that was discussed severa= l times >>>>>>> but I'm still missing the underlying architecture and use case. >>>>>>> >>>>>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>>>>> operated on end user device. >>>>>>> >>>>>>> See the above comment. Please, do not confuse an Identity Wallet >>>>>>> with an Authentication Server (AS). >>>>>>> >>>>>>> Denis >>>>>>> >>>>>>> >>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize >>>>>>> the request or the access to a resource? >>>>>>> [FI] yes, we should make the wording clearer >>>>>>> >>>>>>> Missing Section Interactions: >>>>>>> --> This section shall introduce the notion of interaction before w= e >>>>>>> start listing interaction types. >>>>>>> [FI] yes >>>>>>> >>>>>>> Interaction Types: >>>>>>> --> I prefer a classification with Redirect, Decoupled and Embedded >>>>>>> is. In the draft, we have one redirect and 2 decouple interactions = and >>>>>>> nothing else. >>>>>>> [FI] this should be handled as a specific discussion item. As a >>>>>>> reminder, how would you define embedded? >>>>>>> >>>>>>> In practice there's at least these modes: >>>>>>> - redirect and redirect back >>>>>>> - redirect to different browser or device >>>>>>> - user code >>>>>>> - CIBA >>>>>>> >>>>>>> [FP] This classification is limited. >>>>>>> >>>>>>> - Redirect: same device, same or different user agents (browser, >>>>>>> mobile app, desktop app, ...) >>>>>>> - Decoupled: different devices >>>>>>> - Embedded : RC carries RO authorization to AS >>>>>>> >>>>>>> >>>>>>> >>>>>>> Resource Access Request vs. Resource Request >>>>>>> --> Both are mixed up. No clarification of the context of each >>>>>>> section. >>>>>>> [FI] could you clarify what you'd expect. Btw on this topic, >>>>>>> there's a more general discussion on whether we should make a disti= nction >>>>>>> or not. >>>>>>> >>>>>>> =E2=80=8B[FP]: Here: >>>>>>> >>>>>>> - Resource Access Request: Requesting Access to a resource. >>>>>>> Response is an access token (or any type of grant) >>>>>>> - Resource Request: Request the resource. Response is the >>>>>>> resource (or a corresponding execution) >>>>>>> >>>>>>> >>>>>>> Token Content Negotiation >>>>>>> --> Not expressed as such. This is central to GNAP and not >>>>>>> represented enough in the document. >>>>>>> [FI] right. This should be a specific discussion item. >>>>>>> >>>>>>> Requesting "User" Information >>>>>>> we identify two types of users: RQ and RO. It will be better not to >>>>>>> refer to a user in this draft, but either to a RQ or an RO. >>>>>>> [FI] yes that would avoid potential misunderstandings. Although in >>>>>>> the end, people will translate RQ into user or end-user most of the= time. >>>>>>> Cf in definition, currently we have Requesting Party (RQ, aka >>>>>>> "user") >>>>>>> >>>>>>> >>>>>>> Interaction Again >>>>>>> -> For each interaction type, we will have to describe the protocol >>>>>>> flow and the nature and behavior of involved Roles (Parties), Eleme= nts, >>>>>>> Requests. >>>>>>> [FI] yes >>>>>>> >>>>>>> >>>>>>> [FP] Will these and into tickets? >>>>>>> >>>>>>> Best regards. >>>>>>> /Francis >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>> >>>> --0000000000000a607905b4522474 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It would seem that the mobile OSes would need to support a= new scheme "openid:" ... and provide a mechanism in both the mob= ile browser and mobile apps to detect if an "openid:" handler has= been installed.
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:3= 2 AM Tom Jones <thomascl= inganjones@gmail.com> wrote:
yes - this is the sticking point for s= iop - not sure how it will get resolved.
Peace ..tom


On Tue, Nov 17, 2020 at 10:29 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Got i= t.=C2=A0

So web apps invoke a openid: deep link and = hope there is an app to handle the openid: scheme? ... and that it is the u= ser's wallet rather than some malware that has registered openid: on th= e mobile device?

A native app can attempt to open = a deep link associated with an app, and will fail if the app is not there. = If the app is there, it will be opened, so this can't be used to silent= ly test if an app is present, but it does allow a native app to provide an = alternative experience if an app is not present. I don't think this wor= ks with custom schemes ... and I don't know how it could work from a we= b app on the phone with the current Safari APIs.

A= pple warns against using custom schemes [1] ... but perhaps they can be con= vinced to make openid: a managed scheme similar to mailto:, tel:, sms:, fac= etime: ?



3D""=E1=90=A7

On Tue, Nov 17, 202= 0 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
You ar= e - that is not standard which is opeind://
This is the one step = that still needs to be optimized for SIOP to have good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrot= e:
Hi Tom

I watched your video (I watched at 2X speed)<= /div>

Looks like the employment website app that is usin= g localhost:8765 to communicate with the wallet. Am I correct?
/Dick=C2=A0
3D""=E1=90=A7
On Tue, = Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
W= ell, here's a demo. Note that in this case the AS is not online all of = the time, so it is really implicit flow and the OIDC id-token comes from th= e siop device directly.
(whether this is front-channel or back channel = is no longer an interesting question.)
Now if an always-on AS is re= quired, that is possible, but probably beyond the scope of this effort and = would require something like an agent-in-the-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be/Tq4= hw7X5SW0
Peace ..tom


On Tue, Nov 17, 20= 20 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these i= n the real world, the hurdle isn=E2=80=99t technical compatibility so much = as it is trust compatibility. The RP (client) needs to have some incentive = to trust the assertions and identity information that=E2=80=99s coming from= the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it= =E2=80=99s definitely a question about how to support this =E2=80=9CAS on d= evice=E2=80=9D element. We=E2=80=99ve got the start of it more than OAuth2/= OIDC have by allowing the bootstrap of the process from a starting call: th= e interaction and continuation URIs handed back by the AS don=E2=80=99t nee= d to be the same URIs that the client starts with, so just like SIOP the pr= ocess can start in HTTP and potentially move to other communication channel= s. A major difference is that we aren=E2=80=99t dependent on the assumption= that the user will always be in a browser at some stage, and so the whole = raft of front-channel messages that SIOP relies on doesn=E2=80=99t fly. Tha= t said, we=E2=80=99ve got an opportunity to more explicitly open up alterna= tive communication channels here, and that=E2=80=99s something I=E2=80=99d = like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love= to see a concrete proposal as to how that would work over specific protoco= ls, starting with what we=E2=80=99ve got today.=C2=A0

<= div>=C2=A0=E2=80=94 Justin

On No= v 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Denis, hi Francis,=C2=A0

A= t some point integration with SSI (on the authentication side) will probabl= y occur, including amongst other possibilities SIOP (since they work with O= penID a part of the work will probably be made easier).=C2=A0
That being said, Denis is right. It's not an AS. Technicall= y it's entirely possible to rely on a decentralized wallet (for instanc= e on your phone) and a centralized AS. I know of a few studies on how to de= centralize the AS itself (for instance=C2=A0https://to= ols.ietf.org/html/draft-hardjono-oauth-decentralized-02).
May= be it exists, but I'm still looking for real scenarios (or even archite= ctures) where an AS is deployed directly on a phone, and under the sole aut= hority of the RO, while being compatible with the rest of the world.=C2=A0<= /div>

Cheers,
Fabien

On Tue, Nov 17, 2020= at 5:45 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
=C2=A0[FP] for example, we assume the AS is a server! In mo= st SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagi= ne that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP"= .

An Identity Wallet is not an AS.


Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
=C2=A0[FP] See above (SIOP). There will be a lot of identit= y wallets operated on end user device.

See the above comment. Please, do not confuse an Identi= ty Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes=C2= =A0

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code=
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could yo= u clarify what you'd expect.=C2=A0 Btw on this topic, there's a more general discussion on whether we should make a distinction or not.=C2=A0
=E2=80=8B[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a specific discussion item.=C2=A0=

Requesting "User&quo= t; Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user=C2=A0or end-user most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes=C2= =A0=C2=A0

[FP] Will these and into tickets?

Best regards.
/Francis



--
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
--0000000000000a607905b4522474-- From nobody Tue Nov 17 12:51:01 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 3576C3A09AD; Tue, 17 Nov 2020 12:51:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: txauth@ietf.org Message-ID: <160564626018.15777.9764147069823630656@ietfa.amsl.com> Date: Tue, 17 Nov 2020 12:51:00 -0800 Archived-At: Subject: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-02.txt 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: Tue, 17 Nov 2020 20:51:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Grant Negotiation and Authorization Protocol WG of the IETF. Title : Grant Negotiation and Authorization Protocol Authors : Justin Richer Aaron Parecki Fabien Imbault Filename : draft-ietf-gnap-core-protocol-02.txt Pages : 109 Date : 2020-11-17 Abstract: This document defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This delegation can include access to a set of APIs as well as information passed directly to the software. This document has been prepared by the GNAP working group design team of Kathleen Moriarty, Fabien Imbault, Dick Hardt, Mike Jones, and Justin Richer. This document is intended as a starting point for the working group and includes decision points for discussion and agreement. Many of the features in this proposed protocol can be accomplished in a number of ways. Where possible, the editor has included notes and discussion from the design team regarding the options as understood. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-gnap-core-protocol-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 18 03:16: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 AAE1B3A17C5 for ; Wed, 18 Nov 2020 03:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" 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 WYujnk5osP7C for ; Wed, 18 Nov 2020 03:16:45 -0800 (PST) Received: from DEU01-FR2-obe.outbound.protection.outlook.com (mail-fr2deu01on2070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e24::70e]) (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 00F153A17C7 for ; Wed, 18 Nov 2020 03:16:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FmH2OONAw8x/Bg0+Rcq0v/Hf9mH3V4007NylSvjjQ/TXtQKnk9sWmZX55OxN/Q9gYl0J4p6ON+HTMkxu3aGp7P7I6wibjIZeCnpZbrsytpmLM2WARDxBcNorLJJi2xtuwsFcUwlYEFZmIbH9pwuxqykvXXyicXfoo1pKH/YctvGqjUQWt9c+8cGetrszeWMKoKkzSp9Zbh14HOiRKYseE7bQFpPGrp6xOCXyfsF130RVIwkVTz7uEdWEk03CQ3GuEed/wmz9TFtUWg6UB8Q9pQ8ctt7ZormZtYu+xNrKa/VSt2u1am2KX1b7VPUSQpTdaQ6QRiXKvpqx4nKCzLdTAw== 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=SiNBdddhrHxxXfv/TNbUJlsbuf6r3iVc0oILEltEceE=; b=SBiyKV5EloSqQtrlX95JRzqkVOBouL9F9ZqjFTxW2DfVce+6i0zqolAGkKU3XB7ZAiRjPW1x/faAVV3/Lv9IYtllSF2wMJHmLAuwKQMR6t9qliOGY+oyORiN7tWmgTNrFDY8+DiKaKQggBx7W+z6DU34l45k/OPo+tNHyvnxyUwuLlmltUWOWZVv8iRHD5BWbieSb2FtGRtktvQyoGOvV/T2SIuDA9oy30mydeAFpdplVufwqIC5vUjzds62wC5dG5+HjYLhJg+tEHfRxH//KqhqAiqUGPUoCt5ijGuXPhirDo6Kb8XSyQ9cQcmg7+afw4wX+4GrqrJ6vnG7LMYx2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=adorsys.de; dmarc=pass action=none header.from=adorsys.de; dkim=pass header.d=adorsys.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SiNBdddhrHxxXfv/TNbUJlsbuf6r3iVc0oILEltEceE=; b=z0f3OuFerW/x041ELjQaHSLPUSK5zrjfCmnYzWSg+8apCkDl31VnJ6wYBTcPaqEHUaFvJXwcyGsyYpP5mkIRDmRTD7mj5tU/v+l4j/wnPI5bx9xDE6lsRlvNxfQ8MCGRfRf6DTs+NPnCMyuH086oKyk9djWrD277Ya4vQw6EwbRKDL5V5UKo1JPMjX939HH+PSIF3lmBJca/kCYRz9nei/Q0MD7RQOpR3DZjyHy0YtwJ7cEXQwBGmqJkrC9nI0jSfmhRP2nf+VfO4ZAimbOs0HlEVZ9Fflgr2nu83jYNVveE1hrda7pBMzdcAl8RdL+C78JCswHj7ZJsUJePL4P6KQ== Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:11::11) by FR2P281MB0204.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.16; Wed, 18 Nov 2020 11:16:41 +0000 Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::b06b:117e:61f0:138b]) by FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::b06b:117e:61f0:138b%3]) with mapi id 15.20.3589.021; Wed, 18 Nov 2020 11:16:41 +0000 From: Francis Pouatcha To: "txauth@ietf.org" CC: Dick Hardt , Fabien Imbault , Tom Jones , Denis , Justin Richer Thread-Topic: [GNAP] Review of draft-ietf-gnap-core-protocol-00 Thread-Index: AQHWsiy3H8is1hHc2keFJtXpCHRvoKnGFMOAgATzTCaAAZWSAIAABTGAgAAETgCAAAeTAIAAA4oAgAACAwCAAAZDgIABFPt3 Date: Wed, 18 Nov 2020 11:16:41 +0000 Message-ID: References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=adorsys.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [65.33.157.159] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f4f680ed-f30c-48fe-199a-08d88bb36cf8 x-ms-traffictypediagnostic: FR2P281MB0204: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0+8NMgu+ttopKf5ZgYZyNd1npnkztjcva+IqyU87ykwpOJ0wzu1+s4V05vGg1/B7yir/Azxw10CKRVv7ozWmxPf8WXm/PwhfXoBz3VooJx8GAoyKeAde0Ev68xagc+1+uEg4XvBiCWqyD5F/ajZ+jHgdlV3TeO8igqosh5ecauQRDcd2oKLNle/rWfVWWpF91zuNDq2Jy2Z2dtvB0ZeMTwEIDGBigpWf+k7Aue2mHAzLz5QKsY2MjoKOpOYTRMpJABvsoJvMHxrNULlUrH9X/tTsKpA1AhAB4PFmhNV14bg+j3Ad0ENHXoRaEqCKcbsrM92ddUVIqEFPN74pj769nX3fpcqdvJuf64euzKBpYpMi1XIdLddHsUEpjYqovYZld3hW9qcg2lSx3/81gdVPbXKjm5xnwmwhswrtk4+JFyf0S2aVSMd5fiah97nUWMilcFe7NNoK6uj2MqzJMv+4riz2jBZgXU1d3S4o2rAkviw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(39830400003)(346002)(396003)(376002)(54906003)(55016002)(5660300002)(316002)(478600001)(52536014)(9686003)(7696005)(83380400001)(966005)(76116006)(66946007)(66556008)(8936002)(71200400001)(91956017)(66446008)(8676002)(64756008)(66476007)(2906002)(86362001)(33656002)(4326008)(6506007)(186003)(6916009)(53546011)(19627405001)(166002)(66574015)(26005)(99710200001)(15866825006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: x7s/1hpGQwssM5TchrVd/5R83Lij1/KoU8GOMSM24RZRGE/0hRqt4CfOWLsz42+7nBKLdwW7HuWxfJd89gK8N6J7iw9g62QIXtSUL42vlGLMFsCqJsSGYwo+3y/vgTWmpy1TfRu9ZxM4XmuXxbaJAu9a/iD4k2CleyqOPJwnCWQpIeRNejMa8Ev+hSyVMcOGnpwFWE9Fla5pPJEPMDnv+mCRF6BnsZVXXgC8BIkUvHs4tTD1kANP46e1g8XzZ4iQA1Q8Kk5cUnblblTD3P6A0kmnAJW5UBrd8uZ28+PJsTI6X9v2LWwyZgH00zLmbbIIa5PRqD8oU9oAyBbClHNn7QfK5RTmYxJyXeHbF5Ti5/TidEEyZmbgpba24MiGji1ocvYWOEeDko8wcSKelpddYDL9Z0SMp8DHjCgd8KcsrfnHjFmkqCR0gDl8YRHPEuly0ojMgzLbuxnLupecOY+vNxIERJFckqhbJTJkOoiHlw+ZBp8W1yfoZB77TT/fP8vN7vtGsbbptvUNJr5qZHZ+9GMcnoMB1LLj7l0/USlxr6Z0/QWcnFL66PGyA+VNP4nVnZzO2nhVEAO09gmBu/IS66kdA6prCDe2Vb3RhM3DKk0sNSZe9bSgFAUnnvKaMF7nBGX9EmW4klnt3S8sgh18v6yqIBATqr4g8wBz+PVlGAAQ2i8P0iPS2nvbz23Ua4essX+HxciYm68FFP2bHv0mgSHy3FlpaAo0KqYsodCW+xgoKoviCIsmSteUH47nUWmjqBwlcS6j/riUZaCy4nz+zg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FR2P281MB0106FEBFFB997265C8A9EF878DE10FR2P281MB0106DEUP_" MIME-Version: 1.0 X-OriginatorOrg: adorsys.de X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: f4f680ed-f30c-48fe-199a-08d88bb36cf8 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2020 11:16:41.5624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5e2c5484-e522-479d-91ca-515d6e0ce228 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aLQFqtQSywRf8Fnzag91hisi0QjFIWaOnDAkU1Kxl8PgOIi695r5LbrdDjtKrmrI2X0XZMoHQ6UYD8D9xbQmOJoR4V09QWbo+/vYtJjM0XI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0204 Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 18 Nov 2020 11:16:55 -0000 --_000_FR2P281MB0106FEBFFB997265C8A9EF878DE10FR2P281MB0106DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgYXJlIGRyaWZ0aW5nIGF3YXkgZnJvbSB0aGUgb3JpZ2luYWwgcHJvYmxlbSBzcGFjZS4NCg0K ICAqICAgTXkgb3JpZ2luYWwgbWVudGlvbiB3YXMgYWJvdXQgdGhlICJQT1NUIiByZXF1ZXN0LCB0 aGF0IHN1YnN1bWVzIHRoYXQgdGhlICJBUyIgaXMgYSAiU2VydmVyIi4gRGVzaWduaW5nIGEgbmV3 IHByb3RvY29sLCB3ZSBjYW5ub3QgYWZmb3JkIHRoaXMgbGltaXRhdGlvbi4NCiAgKiAgIEkganVz dCBtZW50aW9uZWQgU0lPUCB0byBzaG93IGEga25vd24gYW5kIGNsb3NlZCBleGFtcGxlPyBMZXQg dXMgbm90IGZvY3VzIG9uIHRoZSBkZXZpY2UgbG9jYWwgZGlzY292ZXJ5IHNjaGVtZSAobGlrZSBv cGVuaWQ6KSBmb3Igbm93Lg0KICAqICAgQXMgY2FwYWJpbGl0eSBvZiBob2xkaW5nIHByaXZhdGUg a2V5cyBvbiB1c2VyIGRldmljZSBldm9sdmVzLCBzZXJ2ZXItYmFzZWQgaXNzdWluZyBvZiB0b2tl biB3aWxsIGJlIGZhZGluZyBvdXQgZ2l2aW5nIHdheSB0byBkZXZpY2UgbG9jYWwgZ2VuZXJhdGlv biBvZiB0b2tlbi4NCg0KV2hpbGUgZGVzaWduaW5nIEdOQVAsIGxldCB1cyBhc3N1bWUgdGhlIEFT LVJvbGUgY2FuIGJlIGV4ZXJjaXNlZCBvbiBhIHVzZXIgZGV2aWNlIGFuZCBkZXNpZ24gdGhlIHBy b3RvY29sIHRvIGhvbm9yIHRoYXQuDQoNCkJlc3QgcmVnYXJkcywNCi9GcmFuY2lzDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogVFhBdXRoIDx0eGF1dGgtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0K U2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTcsIDIwMjAgMToyOCBQTQ0KVG86IFRvbSBKb25lcyA8 dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbT4NCkNjOiBGYWJpZW4gSW1iYXVsdCA8ZmFiaWVu LmltYmF1bHRAZ21haWwuY29tPjsgRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcj47IEdOQVAgTWFp bGluZyBMaXN0IDx0eGF1dGhAaWV0Zi5vcmc+OyBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5l ZHU+DQpTdWJqZWN0OiBSZTogW0dOQVBdIFJldmlldyBvZiBkcmFmdC1pZXRmLWduYXAtY29yZS1w cm90b2NvbC0wMA0KDQpHb3QgaXQuDQoNClNvIHdlYiBhcHBzIGludm9rZSBhIG9wZW5pZDogZGVl cCBsaW5rIGFuZCBob3BlIHRoZXJlIGlzIGFuIGFwcCB0byBoYW5kbGUgdGhlIG9wZW5pZDogc2No ZW1lPyAuLi4gYW5kIHRoYXQgaXQgaXMgdGhlIHVzZXIncyB3YWxsZXQgcmF0aGVyIHRoYW4gc29t ZSBtYWx3YXJlIHRoYXQgaGFzIHJlZ2lzdGVyZWQgb3BlbmlkOiBvbiB0aGUgbW9iaWxlIGRldmlj ZT8NCg0KQSBuYXRpdmUgYXBwIGNhbiBhdHRlbXB0IHRvIG9wZW4gYSBkZWVwIGxpbmsgYXNzb2Np YXRlZCB3aXRoIGFuIGFwcCwgYW5kIHdpbGwgZmFpbCBpZiB0aGUgYXBwIGlzIG5vdCB0aGVyZS4g SWYgdGhlIGFwcCBpcyB0aGVyZSwgaXQgd2lsbCBiZSBvcGVuZWQsIHNvIHRoaXMgY2FuJ3QgYmUg dXNlZCB0byBzaWxlbnRseSB0ZXN0IGlmIGFuIGFwcCBpcyBwcmVzZW50LCBidXQgaXQgZG9lcyBh bGxvdyBhIG5hdGl2ZSBhcHAgdG8gcHJvdmlkZSBhbiBhbHRlcm5hdGl2ZSBleHBlcmllbmNlIGlm IGFuIGFwcCBpcyBub3QgcHJlc2VudC4gSSBkb24ndCB0aGluayB0aGlzIHdvcmtzIHdpdGggY3Vz dG9tIHNjaGVtZXMgLi4uIGFuZCBJIGRvbid0IGtub3cgaG93IGl0IGNvdWxkIHdvcmsgZnJvbSBh IHdlYiBhcHAgb24gdGhlIHBob25lIHdpdGggdGhlIGN1cnJlbnQgU2FmYXJpIEFQSXMuDQoNCkFw cGxlIHdhcm5zIGFnYWluc3QgdXNpbmcgY3VzdG9tIHNjaGVtZXMgWzFdIC4uLiBidXQgcGVyaGFw cyB0aGV5IGNhbiBiZSBjb252aW5jZWQgdG8gbWFrZSBvcGVuaWQ6IGEgbWFuYWdlZCBzY2hlbWUg c2ltaWxhciB0byBtYWlsdG86LCB0ZWw6LCBzbXM6LCBmYWNldGltZTogPw0KDQpbMV0gaHR0cHM6 Ly9kZXZlbG9wZXIuYXBwbGUuY29tL2RvY3VtZW50YXRpb24veGNvZGUvYWxsb3dpbmdfYXBwc19h bmRfd2Vic2l0ZXNfdG9fbGlua190b195b3VyX2NvbnRlbnQvZGVmaW5pbmdfYV9jdXN0b21fdXJs X3NjaGVtZV9mb3JfeW91cl9hcHANCg0KDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29t L3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVu dCZndWlkPTAxMTQ5MGJlLWQzYTAtNGIyYy04YWJiLWU1MTE3NWUzYWUxOV3hkKcNCg0KT24gVHVl LCBOb3YgMTcsIDIwMjAgYXQgMTA6MDYgQU0gVG9tIEpvbmVzIDx0aG9tYXNjbGluZ2Fuam9uZXNA Z21haWwuY29tPG1haWx0bzp0aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tPj4gd3JvdGU6DQpZ b3UgYXJlIC0gdGhhdCBpcyBub3Qgc3RhbmRhcmQgd2hpY2ggaXMgb3BlaW5kOi8vDQpUaGlzIGlz IHRoZSBvbmUgc3RlcCB0aGF0IHN0aWxsIG5lZWRzIHRvIGJlIG9wdGltaXplZCBmb3IgU0lPUCB0 byBoYXZlIGdvb2QgVVguDQpQZWFjZSAuLnRvbQ0KDQoNCk9uIFR1ZSwgTm92IDE3LCAyMDIwIGF0 IDk6NTkgQU0gRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBUb20NCg0KSSB3YXRjaGVkIHlvdXIgdmlkZW8gKEkg d2F0Y2hlZCBhdCAyWCBzcGVlZCkNCg0KTG9va3MgbGlrZSB0aGUgZW1wbG95bWVudCB3ZWJzaXRl IGFwcCB0aGF0IGlzIHVzaW5nIGxvY2FsaG9zdDo4NzY1IHRvIGNvbW11bmljYXRlIHdpdGggdGhl IHdhbGxldC4gQW0gSSBjb3JyZWN0Pw0KDQovRGljaw0KW2h0dHBzOi8vbWFpbGZvb2dhZS5hcHBz cG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJnR5cGU9emVy b2NvbnRlbnQmZ3VpZD0xMWE2MmNlNi05YjRhLTRkNWYtODZjNS1kMmMxMTQzOTVhZWVd4ZCnDQoN Ck9uIFR1ZSwgTm92IDE3LCAyMDIwIGF0IDk6NDYgQU0gVG9tIEpvbmVzIDx0aG9tYXNjbGluZ2Fu am9uZXNAZ21haWwuY29tPG1haWx0bzp0aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tPj4gd3Jv dGU6DQpXZWxsLCBoZXJlJ3MgYSBkZW1vLiBOb3RlIHRoYXQgaW4gdGhpcyBjYXNlIHRoZSBBUyBp cyBub3Qgb25saW5lIGFsbCBvZiB0aGUgdGltZSwgc28gaXQgaXMgcmVhbGx5IGltcGxpY2l0IGZs b3cgYW5kIHRoZSBPSURDIGlkLXRva2VuIGNvbWVzIGZyb20gdGhlIHNpb3AgZGV2aWNlIGRpcmVj dGx5Lg0KKHdoZXRoZXIgdGhpcyBpcyBmcm9udC1jaGFubmVsIG9yIGJhY2sgY2hhbm5lbCBpcyBu byBsb25nZXIgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24uKQ0KTm93IGlmIGFuIGFsd2F5cy1vbiBB UyBpcyByZXF1aXJlZCwgdGhhdCBpcyBwb3NzaWJsZSwgYnV0IHByb2JhYmx5IGJleW9uZCB0aGUg c2NvcGUgb2YgdGhpcyBlZmZvcnQgYW5kIHdvdWxkIHJlcXVpcmUgc29tZXRoaW5nIGxpa2UgYW4g YWdlbnQtaW4tdGhlLXNreSAod2l0aCBkaWFtb25kcykuDQpoZXJlIGlzIHRoZSBsaW5rIHRvIHRo ZSA5IG1pbiB2aWRlbyAgIGh0dHBzOi8veW91dHUuYmUvVHE0aHc3WDVTVzA8aHR0cHM6Ly91cmxk ZWZlbnNlLnVzL3YyL3VybD91PWh0dHBzLTNBX195b3V0dS5iZV9UcTRodzdYNVNXMCZkPUR3TUZh USZjPTJwbEkzaFhIOHd3M2oyZzhwVjE5UUhJZjRTbUtfSS1Fb2xfcDlQMEN0dEUmcj1ENWxuZm9h Mk1WWldFTHFWYmJ6NzFvb2VsYlA3clZHQ2pHRFNCTnZVcFlRJm09aXhzdWRHU3JfZGhHLVNMaWF0 YjRTejlGV3NsbXl3bll5WkFPTGdaeGhsOCZzPWpkTEx5MEcxSlRRQ0FPQlo2UGVVZ0kwa2lDdFZK WHJydTBWVG9ZV2xOWjgmZT0+DQpQZWFjZSAuLnRvbQ0KDQoNCk9uIFR1ZSwgTm92IDE3LCAyMDIw IGF0IDk6MjAgQU0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVy QG1pdC5lZHU+PiB3cm90ZToNClVsdGltYXRlbHksIGluIG1vc3Qgc2l0dWF0aW9ucyBsaWtlIHRo ZXNlIGluIHRoZSByZWFsIHdvcmxkLCB0aGUgaHVyZGxlIGlzbuKAmXQgdGVjaG5pY2FsIGNvbXBh dGliaWxpdHkgc28gbXVjaCBhcyBpdCBpcyB0cnVzdCBjb21wYXRpYmlsaXR5LiBUaGUgUlAgKGNs aWVudCkgbmVlZHMgdG8gaGF2ZSBzb21lIGluY2VudGl2ZSB0byB0cnVzdCB0aGUgYXNzZXJ0aW9u cyBhbmQgaWRlbnRpdHkgaW5mb3JtYXRpb24gdGhhdOKAmXMgY29taW5nIGZyb20gdGhlIEFTLiBU aGUgc2FtZSBpcyB0cnVlIGZvciBhbiBSUyB0cnVzdGluZyB0b2tlbnMgZnJvbSB0aGUgQVMuIFRo ZSBoYXJkIHF1ZXN0aW9uIGlzIGxlc3Mg4oCcaG934oCdIHRvIGRvIHRoYXQgKHdoaWNoIFNTSSBh bnN3ZXJzKSwgYnV0IG1vcmUg4oCcd2h54oCdIHRvIGRvIHRoYXQgKHdoaWNoIFNTSSBkb2VzbuKA mXQgYW5zd2VyIHZlcnkgd2VsbCwgYmVjYXVzZSBpdOKAmXMgYSBoYXJkIHF1ZXN0aW9uKS4NCg0K U3RpbGw6IGl04oCZcyBkZWZpbml0ZWx5IGEgcXVlc3Rpb24gYWJvdXQgaG93IHRvIHN1cHBvcnQg dGhpcyDigJxBUyBvbiBkZXZpY2XigJ0gZWxlbWVudC4gV2XigJl2ZSBnb3QgdGhlIHN0YXJ0IG9m IGl0IG1vcmUgdGhhbiBPQXV0aDIvT0lEQyBoYXZlIGJ5IGFsbG93aW5nIHRoZSBib290c3RyYXAg b2YgdGhlIHByb2Nlc3MgZnJvbSBhIHN0YXJ0aW5nIGNhbGw6IHRoZSBpbnRlcmFjdGlvbiBhbmQg Y29udGludWF0aW9uIFVSSXMgaGFuZGVkIGJhY2sgYnkgdGhlIEFTIGRvbuKAmXQgbmVlZCB0byBi ZSB0aGUgc2FtZSBVUklzIHRoYXQgdGhlIGNsaWVudCBzdGFydHMgd2l0aCwgc28ganVzdCBsaWtl IFNJT1AgdGhlIHByb2Nlc3MgY2FuIHN0YXJ0IGluIEhUVFAgYW5kIHBvdGVudGlhbGx5IG1vdmUg dG8gb3RoZXIgY29tbXVuaWNhdGlvbiBjaGFubmVscy4gQSBtYWpvciBkaWZmZXJlbmNlIGlzIHRo YXQgd2UgYXJlbuKAmXQgZGVwZW5kZW50IG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIHVzZXIg d2lsbCBhbHdheXMgYmUgaW4gYSBicm93c2VyIGF0IHNvbWUgc3RhZ2UsIGFuZCBzbyB0aGUgd2hv bGUgcmFmdCBvZiBmcm9udC1jaGFubmVsIG1lc3NhZ2VzIHRoYXQgU0lPUCByZWxpZXMgb24gZG9l c27igJl0IGZseS4gVGhhdCBzYWlkLCB3ZeKAmXZlIGdvdCBhbiBvcHBvcnR1bml0eSB0byBtb3Jl IGV4cGxpY2l0bHkgb3BlbiB1cCBhbHRlcm5hdGl2ZSBjb21tdW5pY2F0aW9uIGNoYW5uZWxzIGhl cmUsIGFuZCB0aGF04oCZcyBzb21ldGhpbmcgSeKAmWQgbGlrZSB0byBzZWUgZW5naW5lZXJlZCwg ZXZlbiBpZiBpdOKAmXMgYW4gZXh0ZW5zaW9uLiBJ4oCZZCBsb3ZlIHRvIHNlZSBhIGNvbmNyZXRl IHByb3Bvc2FsIGFzIHRvIGhvdyB0aGF0IHdvdWxkIHdvcmsgb3ZlciBzcGVjaWZpYyBwcm90b2Nv bHMsIHN0YXJ0aW5nIHdpdGggd2hhdCB3ZeKAmXZlIGdvdCB0b2RheS4NCg0KIOKAlCBKdXN0aW4N Cg0KT24gTm92IDE3LCAyMDIwLCBhdCAxMjowMyBQTSwgRmFiaWVuIEltYmF1bHQgPGZhYmllbi5p bWJhdWx0QGdtYWlsLmNvbTxtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPj4gd3JvdGU6 DQoNCkhpIERlbmlzLCBoaSBGcmFuY2lzLA0KDQpBdCBzb21lIHBvaW50IGludGVncmF0aW9uIHdp dGggU1NJIChvbiB0aGUgYXV0aGVudGljYXRpb24gc2lkZSkgd2lsbCBwcm9iYWJseSBvY2N1ciwg aW5jbHVkaW5nIGFtb25nc3Qgb3RoZXIgcG9zc2liaWxpdGllcyBTSU9QIChzaW5jZSB0aGV5IHdv cmsgd2l0aCBPcGVuSUQgYSBwYXJ0IG9mIHRoZSB3b3JrIHdpbGwgcHJvYmFibHkgYmUgbWFkZSBl YXNpZXIpLg0KDQpUaGF0IGJlaW5nIHNhaWQsIERlbmlzIGlzIHJpZ2h0LiBJdCdzIG5vdCBhbiBB Uy4gVGVjaG5pY2FsbHkgaXQncyBlbnRpcmVseSBwb3NzaWJsZSB0byByZWx5IG9uIGEgZGVjZW50 cmFsaXplZCB3YWxsZXQgKGZvciBpbnN0YW5jZSBvbiB5b3VyIHBob25lKSBhbmQgYSBjZW50cmFs aXplZCBBUy4gSSBrbm93IG9mIGEgZmV3IHN0dWRpZXMgb24gaG93IHRvIGRlY2VudHJhbGl6ZSB0 aGUgQVMgaXRzZWxmIChmb3IgaW5zdGFuY2UgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWhhcmRqb25vLW9hdXRoLWRlY2VudHJhbGl6ZWQtMDIpLg0KTWF5YmUgaXQgZXhpc3RzLCBi dXQgSSdtIHN0aWxsIGxvb2tpbmcgZm9yIHJlYWwgc2NlbmFyaW9zIChvciBldmVuIGFyY2hpdGVj dHVyZXMpIHdoZXJlIGFuIEFTIGlzIGRlcGxveWVkIGRpcmVjdGx5IG9uIGEgcGhvbmUsIGFuZCB1 bmRlciB0aGUgc29sZSBhdXRob3JpdHkgb2YgdGhlIFJPLCB3aGlsZSBiZWluZyBjb21wYXRpYmxl IHdpdGggdGhlIHJlc3Qgb2YgdGhlIHdvcmxkLg0KDQpDaGVlcnMsDQpGYWJpZW4NCg0KT24gVHVl LCBOb3YgMTcsIDIwMjAgYXQgNTo0NSBQTSBEZW5pcyA8ZGVuaXMuaWV0ZkBmcmVlLmZyPG1haWx0 bzpkZW5pcy5pZXRmQGZyZWUuZnI+PiB3cm90ZToNCkhlbGxvICBGcmFuY2lzLA0KDQpTZWUgdHdv IGNvbW1lbnRzIGluIGxpbmUuDQoNCg0KQikgQ3VycmVudCBEb2N1bWVudA0KDQpSb2xlcyBkZXNj cmlwdGlvbiBzaGFsbCBub3QgaG9sZCBhbnkgYXNzdW1wdGlvbiBvbiB0aGUgcGh5c2ljYWwgc3Ry dWN0dXJlIG9mIHRoZSBwYXJ0eSBmdWxmaWxsaW5nIHRoZSByb2xlcy4NCltGSV0gbm90IHN1cmUg d2hhdCB5b3UgbWVhbg0KIFtGUF0gZm9yIGV4YW1wbGUsIHdlIGFzc3VtZSB0aGUgQVMgaXMgYSBz ZXJ2ZXIhIEluIG1vc3QgU1NJIGJhc2VkIHVzZSBjYXNlcywgdGhlIEFTIHdpbGwgYmUgcnVubmlu ZyBvbiB0aGUgdXNlciBkZXZpY2UuIFNlZSBTSU9QIChodHRwczovL2lkZW50aXR5LmZvdW5kYXRp b24vZGlkLXNpb3AvKS4NCg0KSSBicm93c2VkIHRocm91Z2ggdGhlIHR3byBkcmFmdHMsIGkuZS4g Og0KDQogICogICBEZWNlbnRyYWxpemVkIElkZW50aWZpZXJzIChESURzKSB2MS4wIENvcmUgYXJj aGl0ZWN0dXJlLCBkYXRhIG1vZGVsLCBhbmQgcmVwcmVzZW50YXRpb25zIFczQyBXb3JraW5nIERy YWZ0IDA4IE5vdmVtYmVyIDIwMjANCiAgKiAgIFNlbGYtSXNzdWVkIE9wZW5JRCBDb25uZWN0IFBy b3ZpZGVyIERJRCBQcm9maWxlIHYwLjEuIERJRiBXb3JraW5nIEdyb3VwIERyYWZ0DQoNCkF0IG5v IHBsYWNlIHdpdGhpbiB0aGVzZSB0d28gZG9jdW1lbnRzLCBpdCBpcyBwb3NzaWJsZSB0byBpbWFn aW5lIHRoYXQgInRoZSBBUyB3aWxsIGJlIHJ1bm5pbmcgb24gdGhlIHVzZXIgZGV2aWNlIi4NCg0K RnJvbSBzZWN0aW9uIDMgb2YgdGhlIERJRiBXb3JraW5nIEdyb3VwIERyYWZ0Og0KDQogICAgICAi VW5saWtlIHRoZSBPSURDIEF1dGhvcml6YXRpb24gQ29kZSBGbG93IGFzIHBlciBbT0lEQy5Db3Jl XSwgdGhlIFNJT1Agd2lsbCBub3QgcmV0dXJuIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgUlAiLg0K DQpBbiBJZGVudGl0eSBXYWxsZXQgaXMgbm90IGFuIEFTLg0KDQpSb2xlczoNCi0+IGdyYW50IGVu ZHBvaW50IG9mIHRoZSBBUzogV2h5IGlzIHRoaXMgYSBwb3N0IHJlcXVlc3Q/IFRoaXMgZWxpbWlu YXRlcyB0aGUgY2hhbmNlIG9mIGhhdmluZyB1c2VyIGRldmljZSBob3N0ZWQgQVMgKG5vIHNlcnZl cikuDQpbRkldIHdoYXQgd291bGQgeW91IHByb3Bvc2UgaW5zdGVhZD8NCldvdWxkIGFsc28gYmUg aW50ZXJlc3RlZCB0byB1bmRlcnN0YW5kIGJldHRlciB0aGUgZGVwbG95bWVudCBtb2RlbCB3aGVu IHRoZXJlIGlzIG5vIHNlcnZlci4gVGhhdCdzIHNvbWV0aGluZyB0aGF0IHdhcyBkaXNjdXNzZWQg c2V2ZXJhbCB0aW1lcyBidXQgSSdtIHN0aWxsIG1pc3NpbmcgdGhlIHVuZGVybHlpbmcgYXJjaGl0 ZWN0dXJlIGFuZCB1c2UgY2FzZS4NCiBbRlBdIFNlZSBhYm92ZSAoU0lPUCkuIFRoZXJlIHdpbGwg YmUgYSBsb3Qgb2YgaWRlbnRpdHkgd2FsbGV0cyBvcGVyYXRlZCBvbiBlbmQgdXNlciBkZXZpY2Uu DQoNClNlZSB0aGUgYWJvdmUgY29tbWVudC4gUGxlYXNlLCBkbyBub3QgY29uZnVzZSBhbiBJZGVu dGl0eSBXYWxsZXQgd2l0aCBhbiBBdXRoZW50aWNhdGlvbiBTZXJ2ZXIgKEFTKS4NCg0KRGVuaXMN Cg0KLT4gUmVzb3VyY2UgT3duZXIgKFJPKSA6IEF1dGhvcml6ZXMgdGhlIHJlcXVlc3Q/IERvZXMg aXQgYXV0aG9yaXplIHRoZSByZXF1ZXN0IG9yIHRoZSBhY2Nlc3MgdG8gYSByZXNvdXJjZT8NCltG SV0geWVzLCB3ZSBzaG91bGQgbWFrZSB0aGUgd29yZGluZyBjbGVhcmVyDQoNCk1pc3NpbmcgU2Vj dGlvbiBJbnRlcmFjdGlvbnM6DQotLT4gVGhpcyBzZWN0aW9uIHNoYWxsIGludHJvZHVjZSB0aGUg bm90aW9uIG9mIGludGVyYWN0aW9uIGJlZm9yZSB3ZSBzdGFydCBsaXN0aW5nIGludGVyYWN0aW9u IHR5cGVzLg0KW0ZJXSB5ZXMNCg0KSW50ZXJhY3Rpb24gVHlwZXM6DQotLT4gSSBwcmVmZXIgYSBj bGFzc2lmaWNhdGlvbiB3aXRoIFJlZGlyZWN0LCBEZWNvdXBsZWQgYW5kIEVtYmVkZGVkIGlzLiBJ biB0aGUgZHJhZnQsIHdlIGhhdmUgb25lIHJlZGlyZWN0IGFuZCAyIGRlY291cGxlIGludGVyYWN0 aW9ucyBhbmQgbm90aGluZyBlbHNlLg0KW0ZJXSB0aGlzIHNob3VsZCBiZSBoYW5kbGVkIGFzIGEg c3BlY2lmaWMgZGlzY3Vzc2lvbiBpdGVtLiBBcyBhIHJlbWluZGVyLCBob3cgd291bGQgeW91IGRl ZmluZSBlbWJlZGRlZD8NCg0KSW4gcHJhY3RpY2UgdGhlcmUncyBhdCBsZWFzdCB0aGVzZSBtb2Rl czoNCi0gcmVkaXJlY3QgYW5kIHJlZGlyZWN0IGJhY2sNCi0gcmVkaXJlY3QgdG8gZGlmZmVyZW50 IGJyb3dzZXIgb3IgZGV2aWNlDQotIHVzZXIgY29kZQ0KLSBDSUJBDQpbRlBdIFRoaXMgY2xhc3Np ZmljYXRpb24gaXMgbGltaXRlZC4NCg0KICAqICAgUmVkaXJlY3Q6IHNhbWUgZGV2aWNlLCBzYW1l IG9yIGRpZmZlcmVudCB1c2VyIGFnZW50cyAoYnJvd3NlciwgbW9iaWxlIGFwcCwgZGVza3RvcCBh cHAsIC4uLikNCiAgKiAgIERlY291cGxlZDogZGlmZmVyZW50IGRldmljZXMNCiAgKiAgIEVtYmVk ZGVkIDogUkMgY2FycmllcyBSTyBhdXRob3JpemF0aW9uIHRvIEFTDQoNCg0KUmVzb3VyY2UgQWNj ZXNzIFJlcXVlc3QgdnMuIFJlc291cmNlIFJlcXVlc3QNCi0tPiBCb3RoIGFyZSBtaXhlZCB1cC4g Tm8gY2xhcmlmaWNhdGlvbiBvZiB0aGUgY29udGV4dCBvZiBlYWNoIHNlY3Rpb24uDQpbRkldIGNv dWxkIHlvdSBjbGFyaWZ5IHdoYXQgeW91J2QgZXhwZWN0LiAgQnR3IG9uIHRoaXMgdG9waWMsIHRo ZXJlJ3MgYSBtb3JlIGdlbmVyYWwgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIHdlIHNob3VsZCBtYWtl IGEgZGlzdGluY3Rpb24gb3Igbm90Lg0K4oCLW0ZQXTogSGVyZToNCg0KICAqICAgUmVzb3VyY2Ug QWNjZXNzIFJlcXVlc3Q6IFJlcXVlc3RpbmcgQWNjZXNzIHRvIGEgcmVzb3VyY2UuIFJlc3BvbnNl IGlzIGFuIGFjY2VzcyB0b2tlbiAob3IgYW55IHR5cGUgb2YgZ3JhbnQpDQogICogICBSZXNvdXJj ZSBSZXF1ZXN0OiBSZXF1ZXN0IHRoZSByZXNvdXJjZS4gUmVzcG9uc2UgaXMgdGhlIHJlc291cmNl IChvciBhIGNvcnJlc3BvbmRpbmcgZXhlY3V0aW9uKQ0KDQpUb2tlbiBDb250ZW50IE5lZ290aWF0 aW9uDQotLT4gTm90IGV4cHJlc3NlZCBhcyBzdWNoLiBUaGlzIGlzIGNlbnRyYWwgdG8gR05BUCBh bmQgbm90IHJlcHJlc2VudGVkIGVub3VnaCAgaW4gdGhlIGRvY3VtZW50Lg0KW0ZJXSByaWdodC4g VGhpcyBzaG91bGQgYmUgYSBzcGVjaWZpYyBkaXNjdXNzaW9uIGl0ZW0uDQoNClJlcXVlc3Rpbmcg IlVzZXIiIEluZm9ybWF0aW9uDQp3ZSBpZGVudGlmeSB0d28gdHlwZXMgb2YgdXNlcnM6IFJRIGFu ZCBSTy4gSXQgd2lsbCBiZSBiZXR0ZXIgbm90IHRvIHJlZmVyIHRvIGEgdXNlciBpbiB0aGlzIGRy YWZ0LCBidXQgZWl0aGVyIHRvIGEgUlEgb3IgYW4gUk8uDQpbRkldIHllcyB0aGF0IHdvdWxkIGF2 b2lkIHBvdGVudGlhbCBtaXN1bmRlcnN0YW5kaW5ncy4gQWx0aG91Z2ggaW4gdGhlIGVuZCwgcGVv cGxlIHdpbGwgdHJhbnNsYXRlIFJRIGludG8gdXNlciBvciBlbmQtdXNlciBtb3N0IG9mIHRoZSB0 aW1lLiBDZiBpbiBkZWZpbml0aW9uLCBjdXJyZW50bHkgd2UgaGF2ZSBSZXF1ZXN0aW5nIFBhcnR5 IChSUSwgYWthICJ1c2VyIikNCg0KDQpJbnRlcmFjdGlvbiBBZ2Fpbg0KLT4gRm9yIGVhY2ggaW50 ZXJhY3Rpb24gdHlwZSwgd2Ugd2lsbCBoYXZlIHRvIGRlc2NyaWJlIHRoZSBwcm90b2NvbCBmbG93 IGFuZCB0aGUgbmF0dXJlIGFuZCBiZWhhdmlvciBvZiBpbnZvbHZlZCBSb2xlcyAoUGFydGllcyks IEVsZW1lbnRzLCBSZXF1ZXN0cy4NCltGSV0geWVzDQoNCltGUF0gV2lsbCB0aGVzZSBhbmQgaW50 byB0aWNrZXRzPw0KDQpCZXN0IHJlZ2FyZHMuDQovRnJhbmNpcw0KDQoNCg0KDQoNCi0tDQpUWEF1 dGggbWFpbGluZyBsaXN0DQpUWEF1dGhAaWV0Zi5vcmc8bWFpbHRvOlRYQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQotLQ0KVFhBdXRo IG1haWxpbmcgbGlzdA0KVFhBdXRoQGlldGYub3JnPG1haWx0bzpUWEF1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KDQotLQ0KVFhBdXRo IG1haWxpbmcgbGlzdA0KVFhBdXRoQGlldGYub3JnPG1haWx0bzpUWEF1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KLS0NClRYQXV0aCBt YWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWlsdG86VFhBdXRoQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg== --_000_FR2P281MB0106FEBFFB997265C8A9EF878DE10FR2P281MB0106DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgaWQ9ImFwcGVuZG9uc2VuZCIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1z aXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KV2UgYXJlIGRyaWZ0aW5nIGF3YXkgZnJvbSB0 aGUgb3JpZ2luYWwgcHJvYmxlbSBzcGFjZS48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMnB0OyBjb2xv cjpyZ2IoMCwwLDApIj4NCjx1bD4NCjxsaT5NeSBvcmlnaW5hbCBtZW50aW9uIHdhcyBhYm91dCB0 aGUgJnF1b3Q7UE9TVCZxdW90OyByZXF1ZXN0LCB0aGF0IHN1YnN1bWVzIHRoYXQgdGhlICZxdW90 O0FTJnF1b3Q7IGlzIGEgJnF1b3Q7U2VydmVyJnF1b3Q7LiBEZXNpZ25pbmcgYSBuZXcgcHJvdG9j b2wsIHdlIGNhbm5vdCBhZmZvcmQgdGhpcyBsaW1pdGF0aW9uLjwvbGk+PGxpPkkganVzdCBtZW50 aW9uZWQgU0lPUCB0byBzaG93IGEga25vd24gYW5kIGNsb3NlZCBleGFtcGxlPyBMZXQgdXMgbm90 IGZvY3VzIG9uIHRoZSBkZXZpY2UgbG9jYWwgZGlzY292ZXJ5IHNjaGVtZSAobGlrZSBvcGVuaWQ6 KSBmb3Igbm93LjwvbGk+PGxpPkFzIGNhcGFiaWxpdHkgb2YgaG9sZGluZyBwcml2YXRlIGtleXMg b24gdXNlciBkZXZpY2UgZXZvbHZlcywgc2VydmVyLWJhc2VkIGlzc3Vpbmcgb2YgdG9rZW4gd2ls bCBiZSBmYWRpbmcgb3V0IGdpdmluZyB3YXkgdG8gZGV2aWNlIGxvY2FsIGdlbmVyYXRpb24gb2Yg dG9rZW4uPC9saT48L3VsPg0KPGRpdj5XaGlsZSBkZXNpZ25pbmcgR05BUCwgbGV0IHVzIGFzc3Vt ZSB0aGUgQVMtUm9sZSBjYW4gYmUgZXhlcmNpc2VkIG9uIGEgdXNlciBkZXZpY2UgYW5kIGRlc2ln biB0aGUgcHJvdG9jb2wgdG8gaG9ub3IgdGhhdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXY+L0ZyYW5jaXM8L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsg Zm9udC1zaXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KPC9kaXY+DQo8aHIgdGFiaW5kZXg9 Ii0xIiBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRoOjk4JSI+DQo8ZGl2IGlkPSJk aXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIg Y29sb3I9IiMwMDAwMDAiIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGI+RnJvbTo8L2I+IFRYQXV0 aCAmbHQ7dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0 ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg Tm92ZW1iZXIgMTcsIDIwMjAgMToyOCBQTTxicj4NCjxiPlRvOjwvYj4gVG9tIEpvbmVzICZsdDt0 aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRmFiaWVuIElt YmF1bHQgJmx0O2ZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbSZndDs7IERlbmlzICZsdDtkZW5pcy5p ZXRmQGZyZWUuZnImZ3Q7OyBHTkFQIE1haWxpbmcgTGlzdCAmbHQ7dHhhdXRoQGlldGYub3JnJmd0 OzsgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0dOQVBdIFJldmlldyBvZiBkcmFmdC1pZXRmLWduYXAtY29yZS1wcm90b2NvbC0w MDwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRy Ij5Hb3QgaXQuJm5ic3A7PGJyPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U28gd2ViIGFwcHMg aW52b2tlIGEgb3BlbmlkOiBkZWVwIGxpbmsgYW5kIGhvcGUgdGhlcmUgaXMgYW4gYXBwIHRvIGhh bmRsZSB0aGUgb3BlbmlkOiBzY2hlbWU/IC4uLiBhbmQgdGhhdCBpdCBpcyB0aGUgdXNlcidzIHdh bGxldCByYXRoZXIgdGhhbiBzb21lIG1hbHdhcmUgdGhhdCBoYXMgcmVnaXN0ZXJlZCBvcGVuaWQ6 IG9uIHRoZSBtb2JpbGUgZGV2aWNlPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QSBu YXRpdmUgYXBwIGNhbiBhdHRlbXB0IHRvIG9wZW4gYSBkZWVwIGxpbmsgYXNzb2NpYXRlZCB3aXRo IGFuIGFwcCwgYW5kIHdpbGwgZmFpbCBpZiB0aGUgYXBwIGlzIG5vdCB0aGVyZS4gSWYgdGhlIGFw cCBpcyB0aGVyZSwgaXQgd2lsbCBiZSBvcGVuZWQsIHNvIHRoaXMgY2FuJ3QgYmUgdXNlZCB0byBz aWxlbnRseSB0ZXN0IGlmIGFuIGFwcCBpcyBwcmVzZW50LCBidXQgaXQgZG9lcyBhbGxvdyBhIG5h dGl2ZSBhcHAgdG8gcHJvdmlkZSBhbg0KIGFsdGVybmF0aXZlIGV4cGVyaWVuY2UgaWYgYW4gYXBw IGlzIG5vdCBwcmVzZW50LiBJIGRvbid0IHRoaW5rIHRoaXMgd29ya3Mgd2l0aCBjdXN0b20gc2No ZW1lcyAuLi4gYW5kIEkgZG9uJ3Qga25vdyBob3cgaXQgY291bGQgd29yayBmcm9tIGEgd2ViIGFw cCBvbiB0aGUgcGhvbmUgd2l0aCB0aGUgY3VycmVudCBTYWZhcmkgQVBJcy48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkFwcGxlIHdhcm5zIGFnYWluc3QgdXNpbmcgY3VzdG9tIHNjaGVt ZXMgWzFdIC4uLiBidXQgcGVyaGFwcyB0aGV5IGNhbiBiZSBjb252aW5jZWQgdG8gbWFrZSBvcGVu aWQ6IGEgbWFuYWdlZCBzY2hlbWUgc2ltaWxhciB0byBtYWlsdG86LCB0ZWw6LCBzbXM6LCBmYWNl dGltZTogPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WzFdJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly9kZXZlbG9wZXIuYXBwbGUuY29tL2RvY3VtZW50YXRpb24veGNvZGUvYWxsb3dpbmdf YXBwc19hbmRfd2Vic2l0ZXNfdG9fbGlua190b195b3VyX2NvbnRlbnQvZGVmaW5pbmdfYV9jdXN0 b21fdXJsX3NjaGVtZV9mb3JfeW91cl9hcHAiPmh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxlLmNvbS9k b2N1bWVudGF0aW9uL3hjb2RlL2FsbG93aW5nX2FwcHNfYW5kX3dlYnNpdGVzX3RvX2xpbmtfdG9f eW91cl9jb250ZW50L2RlZmluaW5nX2FfY3VzdG9tX3VybF9zY2hlbWVfZm9yX3lvdXJfYXBwPC9h PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXYgaHNwYWNlPSJzdHJlYWstcHQtbWFyayIgc3R5bGU9Im1heC1oZWlnaHQ6MXB4Ij48aW1nIGFs dD0iIiBzdHlsZT0id2lkdGg6MHB4OyBtYXgtaGVpZ2h0OjBweDsgb3ZlcmZsb3c6aGlkZGVuIiBz cmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEpr ZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTAxMTQ5MGJl LWQzYTAtNGIyYy04YWJiLWU1MTE3NWUzYWUxOSI+PGZvbnQgY29sb3I9IiNmZmZmZmYiIHNpemU9 IjEiPuGQpzwvZm9udD48L2Rpdj4NCjxicj4NCjxkaXYgY2xhc3M9InhfZ21haWxfcXVvdGUiPg0K PGRpdiBkaXI9Imx0ciIgY2xhc3M9InhfZ21haWxfYXR0ciI+T24gVHVlLCBOb3YgMTcsIDIwMjAg YXQgMTA6MDYgQU0gVG9tIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFzY2xpbmdhbmpv bmVzQGdtYWlsLmNvbSI+dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIw NCwyMDQpOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5Zb3UgYXJl IC0gdGhhdCBpcyBub3Qgc3RhbmRhcmQgd2hpY2ggaXMgb3BlaW5kOi8vPC9kaXY+DQo8ZGl2PlRo aXMgaXMgdGhlIG9uZSBzdGVwIHRoYXQgc3RpbGwgbmVlZHMgdG8gYmUgb3B0aW1pemVkIGZvciBT SU9QIHRvIGhhdmUgZ29vZCBVWC48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9 Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+UGVhY2UgLi50b208L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4 X2dtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9uIFR1 ZSwgTm92IDE3LCAyMDIwIGF0IDk6NTkgQU0gRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJ4X2dtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdDoxcHgg c29saWQgcmdiKDIwNCwyMDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRy Ij5IaSBUb20NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkgd2F0Y2hlZCB5b3VyIHZpZGVvIChJ IHdhdGNoZWQgYXQgMlggc3BlZWQpPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Mb29r cyBsaWtlIHRoZSBlbXBsb3ltZW50IHdlYnNpdGUgYXBwIHRoYXQgaXMgdXNpbmcgbG9jYWxob3N0 Ojg3NjUgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgd2FsbGV0LiBBbSBJIGNvcnJlY3Q/PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4vRGljayZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGhzcGFjZT0ic3RyZWFrLXB0LW1hcmsiIHN0eWxlPSJtYXgtaGVpZ2h0OjFweCI+PGltZyBhbHQ9 IiIgc3R5bGU9IndpZHRoOjBweDsgbWF4LWhlaWdodDowcHg7IG92ZXJmbG93OmhpZGRlbiIgc3Jj PSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RF Qm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD0xMWE2MmNlNi05 YjRhLTRkNWYtODZjNS1kMmMxMTQzOTVhZWUiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjZmZmZmZm Ij7hkKc8L2ZvbnQ+PC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4NCjxk aXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9uIFR1ZSwgTm92IDE3LCAyMDIwIGF0 IDk6NDYgQU0gVG9tIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFzY2xpbmdhbmpvbmVz QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJ4X2dtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdDoxcHggc29s aWQgcmdiKDIwNCwyMDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj5X ZWxsLCBoZXJlJ3MgYSBkZW1vLiBOb3RlIHRoYXQgaW4gdGhpcyBjYXNlIHRoZSBBUyBpcyBub3Qg b25saW5lIGFsbCBvZiB0aGUgdGltZSwgc28gaXQgaXMgcmVhbGx5IGltcGxpY2l0IGZsb3cgYW5k IHRoZSBPSURDIGlkLXRva2VuIGNvbWVzIGZyb20gdGhlIHNpb3AgZGV2aWNlIGRpcmVjdGx5Lg0K PGRpdj4od2hldGhlciB0aGlzIGlzIGZyb250LWNoYW5uZWwgb3IgYmFjayBjaGFubmVsIGlzIG5v IGxvbmdlciBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbi4pPGJyPg0KPGRpdj5Ob3cgaWYgYW4gYWx3 YXlzLW9uIEFTIGlzIHJlcXVpcmVkLCB0aGF0IGlzIHBvc3NpYmxlLCBidXQgcHJvYmFibHkgYmV5 b25kIHRoZSBzY29wZSBvZiB0aGlzIGVmZm9ydCBhbmQgd291bGQgcmVxdWlyZSBzb21ldGhpbmcg bGlrZSBhbiBhZ2VudC1pbi10aGUtc2t5Jm5ic3A7KHdpdGggZGlhbW9uZHMpLjwvZGl2Pg0KPGRp dj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPmhlcmUgaXMgdGhlIGxpbmsgdG8gdGhlIDkg bWluIHZpZGVvJm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS51cy92Mi91cmw/dT1odHRwcy0zQV9feW91dHUuYmVfVHE0aHc3WDVTVzAmYW1wO2Q9RHdN RmFRJmFtcDtjPTJwbEkzaFhIOHd3M2oyZzhwVjE5UUhJZjRTbUtfSS1Fb2xfcDlQMEN0dEUmYW1w O3I9RDVsbmZvYTJNVlpXRUxxVmJiejcxb29lbGJQN3JWR0NqR0RTQk52VXBZUSZhbXA7bT1peHN1 ZEdTcl9kaEctU0xpYXRiNFN6OUZXc2xteXduWXlaQU9MZ1p4aGw4JmFtcDtzPWpkTEx5MEcxSlRR Q0FPQlo2UGVVZ0kwa2lDdFZKWHJydTBWVG9ZV2xOWjgmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayIg c3R5bGU9ImZvbnQtc2l6ZToxNHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPmh0dHBz Oi8vPHNwYW4+eW91dHU8L3NwYW4+LjxzcGFuPmJlPC9zcGFuPi9UcTRodzdYNVNXMDwvc3Bhbj48 L2E+PGJyIGNsZWFyPSJhbGwiPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2PlBlYWNlIC4udG9tPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3Rl Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9uIFR1ZSwgTm92IDE3LCAy MDIwIGF0IDk6MjAgQU0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJA bWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwy MDQpOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXY+VWx0aW1hdGVseSwgaW4gbW9zdCBzaXR1YXRp b25zIGxpa2UgdGhlc2UgaW4gdGhlIHJlYWwgd29ybGQsIHRoZSBodXJkbGUgaXNu4oCZdCB0ZWNo bmljYWwgY29tcGF0aWJpbGl0eSBzbyBtdWNoIGFzIGl0IGlzIHRydXN0IGNvbXBhdGliaWxpdHku IFRoZSBSUCAoY2xpZW50KSBuZWVkcyB0byBoYXZlIHNvbWUgaW5jZW50aXZlIHRvIHRydXN0IHRo ZSBhc3NlcnRpb25zIGFuZCBpZGVudGl0eSBpbmZvcm1hdGlvbiB0aGF04oCZcyBjb21pbmcgZnJv bQ0KIHRoZSBBUy4gVGhlIHNhbWUgaXMgdHJ1ZSBmb3IgYW4gUlMgdHJ1c3RpbmcgdG9rZW5zIGZy b20gdGhlIEFTLiBUaGUgaGFyZCBxdWVzdGlvbiBpcyBsZXNzIOKAnGhvd+KAnSB0byBkbyB0aGF0 ICh3aGljaCBTU0kgYW5zd2VycyksIGJ1dCBtb3JlIOKAnHdoeeKAnSB0byBkbyB0aGF0ICh3aGlj aCBTU0kgZG9lc27igJl0IGFuc3dlciB2ZXJ5IHdlbGwsIGJlY2F1c2UgaXTigJlzIGEgaGFyZCBx dWVzdGlvbikuDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TdGlsbDogaXTigJlzIGRlZmluaXRl bHkgYSBxdWVzdGlvbiBhYm91dCBob3cgdG8gc3VwcG9ydCB0aGlzIOKAnEFTIG9uIGRldmljZeKA nSBlbGVtZW50LiBXZeKAmXZlIGdvdCB0aGUgc3RhcnQgb2YgaXQgbW9yZSB0aGFuIE9BdXRoMi9P SURDIGhhdmUgYnkgYWxsb3dpbmcgdGhlIGJvb3RzdHJhcCBvZiB0aGUgcHJvY2VzcyBmcm9tIGEg c3RhcnRpbmcgY2FsbDogdGhlIGludGVyYWN0aW9uIGFuZCBjb250aW51YXRpb24gVVJJcyBoYW5k ZWQgYmFjayBieQ0KIHRoZSBBUyBkb27igJl0IG5lZWQgdG8gYmUgdGhlIHNhbWUgVVJJcyB0aGF0 IHRoZSBjbGllbnQgc3RhcnRzIHdpdGgsIHNvIGp1c3QgbGlrZSBTSU9QIHRoZSBwcm9jZXNzIGNh biBzdGFydCBpbiBIVFRQIGFuZCBwb3RlbnRpYWxseSBtb3ZlIHRvIG90aGVyIGNvbW11bmljYXRp b24gY2hhbm5lbHMuIEEgbWFqb3IgZGlmZmVyZW5jZSBpcyB0aGF0IHdlIGFyZW7igJl0IGRlcGVu ZGVudCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSB1c2VyIHdpbGwgYWx3YXlzDQogYmUgaW4g YSBicm93c2VyIGF0IHNvbWUgc3RhZ2UsIGFuZCBzbyB0aGUgd2hvbGUgcmFmdCBvZiBmcm9udC1j aGFubmVsIG1lc3NhZ2VzIHRoYXQgU0lPUCByZWxpZXMgb24gZG9lc27igJl0IGZseS4gVGhhdCBz YWlkLCB3ZeKAmXZlIGdvdCBhbiBvcHBvcnR1bml0eSB0byBtb3JlIGV4cGxpY2l0bHkgb3BlbiB1 cCBhbHRlcm5hdGl2ZSBjb21tdW5pY2F0aW9uIGNoYW5uZWxzIGhlcmUsIGFuZCB0aGF04oCZcyBz b21ldGhpbmcgSeKAmWQgbGlrZSB0byBzZWUgZW5naW5lZXJlZCwNCiBldmVuIGlmIGl04oCZcyBh biBleHRlbnNpb24uIEnigJlkIGxvdmUgdG8gc2VlIGEgY29uY3JldGUgcHJvcG9zYWwgYXMgdG8g aG93IHRoYXQgd291bGQgd29yayBvdmVyIHNwZWNpZmljIHByb3RvY29scywgc3RhcnRpbmcgd2l0 aCB3aGF0IHdl4oCZdmUgZ290IHRvZGF5LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+Jm5ic3A74oCUIEp1c3Rpbjxicj4NCjxkaXY+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQo8ZGl2Pk9uIE5vdiAxNywgMjAyMCwgYXQgMTI6MDMgUE0sIEZhYmllbiBJbWJhdWx0 ICZsdDs8YSBocmVmPSJtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnI+ DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+SGkgRGVuaXMsIGhpIEZyYW5jaXMsJm5ic3A7DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5BdCBzb21lIHBvaW50IGludGVncmF0aW9uIHdpdGggU1NJIChv biB0aGUgYXV0aGVudGljYXRpb24gc2lkZSkgd2lsbCBwcm9iYWJseSBvY2N1ciwgaW5jbHVkaW5n IGFtb25nc3Qgb3RoZXIgcG9zc2liaWxpdGllcyBTSU9QIChzaW5jZSB0aGV5IHdvcmsgd2l0aCBP cGVuSUQgYSBwYXJ0IG9mIHRoZSB3b3JrIHdpbGwgcHJvYmFibHkgYmUgbWFkZSBlYXNpZXIpLiZu YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhdCBiZWluZyBzYWlkLCBEZW5p cyBpcyByaWdodC4gSXQncyBub3QgYW4gQVMuIFRlY2huaWNhbGx5IGl0J3MgZW50aXJlbHkgcG9z c2libGUgdG8gcmVseSBvbiBhIGRlY2VudHJhbGl6ZWQgd2FsbGV0IChmb3IgaW5zdGFuY2Ugb24g eW91ciBwaG9uZSkgYW5kIGEgY2VudHJhbGl6ZWQgQVMuIEkga25vdyBvZiBhIGZldyBzdHVkaWVz IG9uIGhvdyB0byBkZWNlbnRyYWxpemUgdGhlIEFTIGl0c2VsZiAoZm9yIGluc3RhbmNlJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmRqb25vLW9hdXRo LWRlY2VudHJhbGl6ZWQtMDIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaGFyZGpvbm8tb2F1dGgtZGVjZW50cmFsaXplZC0wMjwvYT4pLjwvZGl2Pg0K PGRpdj5NYXliZSBpdCBleGlzdHMsIGJ1dCBJJ20gc3RpbGwgbG9va2luZyBmb3IgcmVhbCBzY2Vu YXJpb3MgKG9yIGV2ZW4gYXJjaGl0ZWN0dXJlcykgd2hlcmUgYW4gQVMgaXMgZGVwbG95ZWQgZGly ZWN0bHkgb24gYSBwaG9uZSwgYW5kIHVuZGVyIHRoZSBzb2xlIGF1dGhvcml0eSBvZiB0aGUgUk8s IHdoaWxlIGJlaW5nIGNvbXBhdGlibGUgd2l0aCB0aGUgcmVzdCBvZiB0aGUgd29ybGQuJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaGVlcnMsPC9kaXY+DQo8ZGl2PkZhYmll bjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4NCjxkaXYg ZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9uIFR1ZSwgTm92IDE3LCAyMDIwIGF0IDU6 NDUgUE0gRGVuaXMgJmx0OzxhIGhyZWY9Im1haWx0bzpkZW5pcy5pZXRmQGZyZWUuZnIiIHRhcmdl dD0iX2JsYW5rIj5kZW5pcy5pZXRmQGZyZWUuZnI8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4OyBib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTsgcGFkZGlu Zy1sZWZ0OjFleCI+DQo8ZGl2Pg0KPGRpdj5IZWxsbyZuYnNwOyBGcmFuY2lzLDwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+U2VlIHR3byBjb21tZW50cyBpbiBsaW5lLjxicj4NCjwvZGl2 Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItY29sb3I6cmdiKDIwMCwy MDAsMjAwKTsgYm9yZGVyLWxlZnQtd2lkdGg6M3B4OyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsg cGFkZGluZy1sZWZ0OjFleDsgbWFyZ2luLWxlZnQ6MC44ZXg7IGNvbG9yOnJnYigxMDIsMTAyLDEw MikiPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweDsgZm9udC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0 aWNhLHNhbnMtc2VyaWYiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyB0ZXh0LWFsaWduOmxlZnQ7IGJhY2tncm91bmQtY29sb3I6 d2hpdGUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+QikgQ3VycmVudCBEb2N1bWVudDwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46MHB4Ij48Zm9udD5Sb2xlcyBkZXNjcmlwdGlvbiBzaGFsbCBub3QgaG9sZCBhbnkgYXNzdW1w dGlvbiBvbiB0aGUgcGh5c2ljYWwgc3RydWN0dXJlIG9mIHRoZSBwYXJ0eSBmdWxmaWxsaW5nIHRo ZSByb2xlcy48L2ZvbnQ+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVk Ij5bRkldIG5vdCBzdXJlIHdoYXQgeW91IG1lYW48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7 IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPiZuYnNw O1tGUF0gZm9yIGV4YW1wbGUsIHdlIGFzc3VtZSB0aGUgQVMgaXMgYSBzZXJ2ZXIhIEluIG1vc3Qg U1NJIGJhc2VkIHVzZSBjYXNlcywgdGhlIEFTIHdpbGwgYmUgcnVubmluZyBvbiB0aGUgdXNlciBk ZXZpY2UuIFNlZSBTSU9QICg8YSBocmVmPSJodHRwczovL2lkZW50aXR5LmZvdW5kYXRpb24vZGlk LXNpb3AvIiByZWw9Im5vb3BlbmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0i bWFyZ2luOjBweCI+aHR0cHM6Ly9pZGVudGl0eS5mb3VuZGF0aW9uL2RpZC1zaW9wLzwvYT4pLjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD5J IGJyb3dzZWQgdGhyb3VnaCB0aGUgdHdvIGRyYWZ0cywgaS5lLiA6PC9wPg0KPHVsPg0KPGxpPkRl Y2VudHJhbGl6ZWQgSWRlbnRpZmllcnMgKERJRHMpIHYxLjAgQ29yZSBhcmNoaXRlY3R1cmUsIGRh dGEgbW9kZWwsIGFuZCByZXByZXNlbnRhdGlvbnMgVzNDIFdvcmtpbmcgRHJhZnQgMDggTm92ZW1i ZXIgMjAyMA0KPC9saT48bGk+U2VsZi1Jc3N1ZWQgT3BlbklEIENvbm5lY3QgUHJvdmlkZXIgRElE IFByb2ZpbGUgdjAuMS4gRElGIFdvcmtpbmcgR3JvdXAgRHJhZnQ8L2xpPjwvdWw+DQo8cD5BdCBu byBwbGFjZSB3aXRoaW4gdGhlc2UgdHdvIGRvY3VtZW50cywgaXQgaXMgcG9zc2libGUgdG8gaW1h Z2luZSB0aGF0ICZxdW90O3RoZSBBUyB3aWxsIGJlIHJ1bm5pbmcgb24gdGhlIHVzZXIgZGV2aWNl JnF1b3Q7Ljxicj4NCjwvcD4NCjxwPkZyb20gc2VjdGlvbiAzIG9mIHRoZSBESUYgV29ya2luZyBH cm91cCBEcmFmdDo8L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 VW5saWtlIHRoZSBPSURDIEF1dGhvcml6YXRpb24gQ29kZSBGbG93IGFzIHBlciBbT0lEQy5Db3Jl XSwgdGhlIFNJT1Agd2lsbCBub3QgcmV0dXJuIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgUlAmcXVv dDsuPGJyPg0KPC9wPg0KPHA+QW4gSWRlbnRpdHkgV2FsbGV0IGlzIG5vdCBhbiBBUy4gPGJyPg0K PC9wPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNr Z3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBweDsgZm9udC1zaXplOjE1cHg7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+ PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWNvbG9yOnJnYigyMDAsMjAw LDIwMCk7IGJvcmRlci1sZWZ0LXdpZHRoOjNweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBh ZGRpbmctbGVmdDoxZXg7IG1hcmdpbi1sZWZ0OjAuOGV4OyBjb2xvcjpyZ2IoMTAyLDEwMiwxMDIp Ij4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdp bjowcHg7IGZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGlj YSxzYW5zLXNlcmlmIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IHRleHQtYWxpZ246bGVmdDsg YmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYg c3R5bGU9Im1hcmdpbjowcHgiPlJvbGVzOiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBweCI+LSZndDsgZ3JhbnQgZW5kcG9pbnQgb2YgdGhlIEFTOiBXaHkgaXMgdGhpcyBhIHBvc3Qg cmVxdWVzdD8gVGhpcyBlbGltaW5hdGVzIHRoZSBjaGFuY2Ugb2YgaGF2aW5nIHVzZXIgZGV2aWNl IGhvc3RlZCBBUyAobm8gc2VydmVyKS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+W0ZJXSB3aGF0 IHdvdWxkIHlvdSBwcm9wb3NlIGluc3RlYWQ/PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+V291bGQgYWxzbyBiZSBpbnRlcmVzdGVkIHRvIHVu ZGVyc3RhbmQgYmV0dGVyIHRoZSBkZXBsb3ltZW50IG1vZGVsIHdoZW4gdGhlcmUgaXMgbm8gc2Vy dmVyLiBUaGF0J3Mgc29tZXRoaW5nIHRoYXQgd2FzIGRpc2N1c3NlZCBzZXZlcmFsIHRpbWVzIGJ1 dCBJJ20gc3RpbGwgbWlzc2luZyB0aGUgdW5kZXJseWluZyBhcmNoaXRlY3R1cmUgYW5kIHVzZSBj YXNlLjwvZm9udD48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7 IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPiZuYnNw O1tGUF0gU2VlIGFib3ZlIChTSU9QKS4gVGhlcmUgd2lsbCBiZSBhIGxvdCBvZiBpZGVudGl0eSB3 YWxsZXRzIG9wZXJhdGVkIG9uIGVuZCB1c2VyIGRldmljZS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+U2VlIHRoZSBhYm92ZSBjb21tZW50 LiBQbGVhc2UsIGRvIG5vdCBjb25mdXNlIGFuIElkZW50aXR5IFdhbGxldCB3aXRoIGFuIEF1dGhl bnRpY2F0aW9uIFNlcnZlciAoQVMpLjwvcD4NCjxwPkRlbmlzPGJyPg0KPC9wPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNTUsMjU1LDI1NSkiPjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1j b2xvcjpyZ2IoMjAwLDIwMCwyMDApOyBib3JkZXItbGVmdC13aWR0aDozcHg7IGJvcmRlci1sZWZ0 LXN0eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4OyBtYXJnaW4tbGVmdDowLjhleDsgY29sb3I6 cmdiKDEwMiwxMDIsMTAyKSI+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTJwdDsgZm9udC1mYW1pbHk6Q2FsaWJy aSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyB0 ZXh0LWFsaWduOmxlZnQ7IGJhY2tncm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4tJmd0OyBSZXNvdXJjZSBPd25lciAo Uk8pIDogQXV0aG9yaXplcyB0aGUgcmVxdWVzdD8gRG9lcyBpdCBhdXRob3JpemUgdGhlIHJlcXVl c3Qgb3IgdGhlIGFjY2VzcyB0byBhIHJlc291cmNlPzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj5b RkldIHllcywgd2Ugc2hvdWxkIG1ha2UgdGhlIHdvcmRpbmcgY2xlYXJlcjwvZm9udD48L2Rpdj4N CjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjow cHg7IGZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxz YW5zLXNlcmlmIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IHRleHQtYWxpZ246bGVmdDsgYmFj a2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5 bGU9Im1hcmdpbjowcHgiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+TWlz c2luZyBTZWN0aW9uIEludGVyYWN0aW9uczo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgi Pi0tJmd0OyBUaGlzIHNlY3Rpb24gc2hhbGwgaW50cm9kdWNlIHRoZSBub3Rpb24gb2YgaW50ZXJh Y3Rpb24gYmVmb3JlIHdlIHN0YXJ0IGxpc3RpbmcgaW50ZXJhY3Rpb24gdHlwZXMuPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxm b250IGNvbG9yPSJyZWQiPltGSV0geWVzJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBkaXI9Imx0 ciIgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNTUsMjU1LDI1NSkiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjEycHQ7 IGZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOjBweDsgdGV4dC1hbGlnbjpsZWZ0OyBiYWNrZ3JvdW5kLWNvbG9yOndoaXRl Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIi IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZTox MnB0OyBmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjowcHg7IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3 aGl0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgi PkludGVyYWN0aW9uIFR5cGVzOjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+LS0mZ3Q7 IEkgcHJlZmVyIGEgY2xhc3NpZmljYXRpb24gd2l0aCBSZWRpcmVjdCwgRGVjb3VwbGVkIGFuZCBF bWJlZGRlZCBpcy4gSW4gdGhlIGRyYWZ0LCB3ZSBoYXZlIG9uZSByZWRpcmVjdCBhbmQgMiBkZWNv dXBsZSBpbnRlcmFjdGlvbnMgYW5kIG5vdGhpbmcgZWxzZS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJl ZCI+W0ZJXSB0aGlzIHNob3VsZCBiZSBoYW5kbGVkIGFzIGEgc3BlY2lmaWMgZGlzY3Vzc2lvbiBp dGVtLiBBcyBhIHJlbWluZGVyLCBob3cgd291bGQgeW91IGRlZmluZSBlbWJlZGRlZD88L2ZvbnQ+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj48YnI+DQo8 L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdp bjowcHgiPjxmb250IGNvbG9yPSJyZWQiPkluIHByYWN0aWNlIHRoZXJlJ3MgYXQgbGVhc3QgdGhl c2UgbW9kZXM6PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZvbnQgY29s b3I9InJlZCI+LSByZWRpcmVjdCBhbmQgcmVkaXJlY3QgYmFjazwvZm9udD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJyZWQiPi0gcmVkaXJlY3QgdG8gZGlmZmVy ZW50IGJyb3dzZXIgb3IgZGV2aWNlPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBw eCI+PGZvbnQgY29sb3I9InJlZCI+LSB1c2VyIGNvZGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj4tIENJQkE8L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4 OyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBweCI+W0ZQXSBUaGlzIGNsYXNzaWZpY2F0aW9uIGlzIGxpbWl0ZWQuPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9y OnJnYigyNTUsMjU1LDI1NSkiPg0KPHVsPg0KPGxpPlJlZGlyZWN0OiBzYW1lIGRldmljZSwgc2Ft ZSBvciBkaWZmZXJlbnQgdXNlciBhZ2VudHMgKGJyb3dzZXIsIG1vYmlsZSBhcHAsIGRlc2t0b3Ag YXBwLCAuLi4pPC9saT48bGk+RGVjb3VwbGVkOiBkaWZmZXJlbnQgZGV2aWNlczwvbGk+PGxpPkVt YmVkZGVkIDogUkMgY2FycmllcyBSTyBhdXRob3JpemF0aW9uIHRvIEFTPC9saT48L3VsPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1j b2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxl PSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxMnB0OyBm b250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjowcHg7IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxicj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyLWNvbG9yOnJnYigyMDAsMjAwLDIwMCk7IGJvcmRlci1sZWZ0LXdpZHRoOjNweDsg Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBhZGRpbmctbGVmdDoxZXg7IG1hcmdpbi1sZWZ0OjAu OGV4OyBjb2xvcjpyZ2IoMTAyLDEwMiwxMDIpIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJn aW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxMnB0OyBmb250LWZh bWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjowcHg7IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPlJlc291cmNlIEFj Y2VzcyBSZXF1ZXN0IHZzLiBSZXNvdXJjZSBSZXF1ZXN0PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46MHB4Ij4tLSZndDsgQm90aCBhcmUgbWl4ZWQgdXAuIE5vIGNsYXJpZmljYXRpb24gb2YgdGhl IGNvbnRleHQgb2YgZWFjaCBzZWN0aW9uLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj5bRkldIGNv dWxkIHlvdSBjbGFyaWZ5IHdoYXQgeW91J2QgZXhwZWN0LiZuYnNwOyBCdHcgb24gdGhpcyB0b3Bp YywgdGhlcmUncyBhIG1vcmUgZ2VuZXJhbCBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgd2Ugc2hvdWxk IG1ha2UgYSBkaXN0aW5jdGlvbiBvciBub3QuJm5ic3A7PC9mb250PjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjE1cHg7IGJhY2tncm91bmQt Y29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+PGZvbnQgY29sb3I9InJlZCI+PHNwYW4gc3R5bGU9Im1h cmdpbjowcHg7IGNvbG9yOnJnYigwLDM2LDgxKSI+4oCLW0ZQXTogSGVyZTo8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjE1cHg7IGJhY2tncm91 bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQo8dWw+DQo8bGk+PGZvbnQgY29sb3I9InJlZCI+ PHNwYW4gc3R5bGU9Im1hcmdpbjowcHg7IGNvbG9yOnJnYigwLDM2LDgxKSI+PHNwYW4gc3R5bGU9 Im1hcmdpbjowcHg7IGZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2Vy aWY7IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+UmVzb3VyY2UgQWNj ZXNzIFJlcXVlc3Q6IFJlcXVlc3RpbmcgQWNjZXNzIHRvIGEgcmVzb3VyY2UuIFJlc3BvbnNlIGlz IGFuIGFjY2Vzcw0KIHRva2VuIChvciBhbnkgdHlwZSBvZiBncmFudCk8L3NwYW4+PC9zcGFuPjwv Zm9udD48L2xpPjxsaT48Zm9udCBjb2xvcj0icmVkIj48c3BhbiBzdHlsZT0ibWFyZ2luOjBweDsg Y29sb3I6cmdiKDAsMzYsODEpIj48c3BhbiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1mYW1pbHk6 Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgdGV4dC1hbGlnbjpsZWZ0OyBiYWNr Z3JvdW5kLWNvbG9yOndoaXRlIj5SZXNvdXJjZSBSZXF1ZXN0OiBSZXF1ZXN0IHRoZSByZXNvdXJj ZS4gUmVzcG9uc2UgaXMgdGhlIHJlc291cmNlIChvciBhIGNvcnJlc3BvbmRpbmcNCiBleGVjdXRp b24pPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRy IiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6 MTJwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyB0ZXh0LWFsaWduOmxlZnQ7IGJhY2tncm91bmQtY29sb3I6 d2hpdGUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWNvbG9yOnJnYigyMDAsMjAw LDIwMCk7IGJvcmRlci1sZWZ0LXdpZHRoOjNweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBh ZGRpbmctbGVmdDoxZXg7IG1hcmdpbi1sZWZ0OjAuOGV4OyBjb2xvcjpyZ2IoMTAyLDEwMiwxMDIp Ij4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdp bjowcHg7IGZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGlj YSxzYW5zLXNlcmlmIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IHRleHQtYWxpZ246bGVmdDsg YmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYg c3R5bGU9Im1hcmdpbjowcHgiPlRva2VuIENvbnRlbnQgTmVnb3RpYXRpb248L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjowcHgiPi0tJmd0OyBOb3QgZXhwcmVzc2VkIGFzIHN1Y2guIFRoaXMgaXMg Y2VudHJhbCB0byBHTkFQIGFuZCBub3QgcmVwcmVzZW50ZWQgZW5vdWdoJm5ic3A7IGluIHRoZSBk b2N1bWVudC48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+W0ZJXSByaWdodC4gVGhpcyBzaG91bGQg YmUgYSBzcGVjaWZpYyBkaXNjdXNzaW9uIGl0ZW0uJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBk aXI9Imx0ciIgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9u dC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2Vy aWYiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgdGV4dC1hbGlnbjpsZWZ0OyBiYWNrZ3JvdW5k LWNvbG9yOndoaXRlIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij5SZXF1ZXN0aW5n ICZxdW90O1VzZXImcXVvdDsgSW5mb3JtYXRpb248L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjow cHgiPndlIGlkZW50aWZ5IHR3byB0eXBlcyBvZiB1c2VyczogUlEgYW5kIFJPLiBJdCB3aWxsIGJl IGJldHRlciBub3QgdG8gcmVmZXIgdG8gYSB1c2VyIGluIHRoaXMgZHJhZnQsIGJ1dCBlaXRoZXIg dG8gYSBSUSBvciBhbiBSTy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+W0ZJXSB5ZXMgdGhhdCB3 b3VsZCBhdm9pZCBwb3RlbnRpYWwgbWlzdW5kZXJzdGFuZGluZ3MuIEFsdGhvdWdoIGluIHRoZSBl bmQsIHBlb3BsZSB3aWxsIHRyYW5zbGF0ZSBSUSBpbnRvIHVzZXImbmJzcDtvciBlbmQtdXNlciBt b3N0IG9mIHRoZSB0aW1lLiBDZiBpbiBkZWZpbml0aW9uLCBjdXJyZW50bHkgd2UgaGF2ZSZuYnNw OzwvZm9udD48c3Bhbj48Zm9udCBjb2xvcj0icmVkIj5SZXF1ZXN0aW5nDQogUGFydHkgKFJRLCBh a2EgJnF1b3Q7dXNlciZxdW90Oyk8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGJyPg0KPGRpdiBkaXI9 Imx0ciIgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1z aXplOjEycHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgdGV4dC1hbGlnbjpsZWZ0OyBiYWNrZ3JvdW5kLWNv bG9yOndoaXRlIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBweCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij5JbnRlcmFjdGlvbiBB Z2FpbjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 MHB4Ij4tJmd0OyBGb3IgZWFjaCBpbnRlcmFjdGlvbiB0eXBlLCB3ZSB3aWxsIGhhdmUgdG8gZGVz Y3JpYmUgdGhlIHByb3RvY29sIGZsb3cgYW5kIHRoZSBuYXR1cmUgYW5kIGJlaGF2aW9yIG9mIGlu dm9sdmVkIFJvbGVzIChQYXJ0aWVzKSwgRWxlbWVudHMsIFJlcXVlc3RzLjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgi Pjxmb250IGNvbG9yPSJyZWQiPltGSV0geWVzJm5ic3A7Jm5ic3A7PC9mb250PjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWws SGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgdGV4dC1hbGln bjpsZWZ0OyBiYWNrZ3JvdW5kLWNvbG9yOndoaXRlIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBi YWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPltGUF0gV2lsbCB0aGVzZSBhbmQgaW50 byB0aWNrZXRzPzwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjE1cHg7 IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1 LDI1NSwyNTUpIj5CZXN0IHJlZ2FyZHMuPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBm b250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4vRnJhbmNp czwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8Zmll bGRzZXQ+PC9maWVsZHNldD4gPC9ibG9ja3F1b3RlPg0KPHA+PGJyPg0KPC9wPg0KPC9kaXY+DQot LSA8YnI+DQpUWEF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRYQXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRYQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90eGF1dGg8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQotLSA8YnI+DQpUWEF1 dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRYQXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPlRYQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxicj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KLS0gPGJyPg0KVFhB dXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUWEF1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5UWEF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRo PC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KLS0gPGJyPg0KVFhBdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUWEF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5UWEF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxicj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FR2P281MB0106FEBFFB997265C8A9EF878DE10FR2P281MB0106DEUP_-- From nobody Wed Nov 18 03:35: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 B9E433A17CE for ; Wed, 18 Nov 2020 03:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTTPS_HTTP_MISMATCH=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=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 cLQ-ldIX4zhh for ; Wed, 18 Nov 2020 03:35:20 -0800 (PST) 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 217F73A10F1 for ; Wed, 18 Nov 2020 03:35:20 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id u21so1596848iol.12 for ; Wed, 18 Nov 2020 03:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZiVpODv67ut4fhvs3AAM6ObbBLfx/7r46AvVpIUCRM0=; b=uuwOGO6+QYOxfCrd3/u6dPJwl80XWHBcMBDDBg/6PqSx06e5qE3C31hHvWPFYPZwJp OSepszw7qzuz3wuj4l4PEzbpfDtCFbjoGt3gSkJPzqEx2lwaD5kPX4oR22hN1ZRjnKUj DYV/KBJH7yFtssUEVDiD5GJ1OM/8fIXDhZErTyF1S/qUju5loLDxwUuDOrWnNi7lqrpE lMbKyj49P/2kcGxlPsGRtkOJ52MrsMSfE+/EFueiU88AB1w+rWMz6ccT11ZZsLm52+XW LXmy+3kuV5ShlGvVXOOUfzHp3yU6Z0nuimleEB1TaREZyD+xG1lWiMgIAMmI/KeasqzD 6J2Q== 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=ZiVpODv67ut4fhvs3AAM6ObbBLfx/7r46AvVpIUCRM0=; b=N9az0GMBUlvwVNwamqm0AnEvUYJ3nXT878EBg7WyYHYF8O+f5wTqQHeO8JeRF3yDB4 5w6UvhGzT4QdZAu5zGrxonIvi8C4wa84DHCW5vgyX919z5uxlz1ziX50r6hHsRmvqSZK uThxL1qJ5DkovkvG0HL7qf52ARJ9yBdJdfGMLDdF4Hz7kgDusjmle1KaS5psV28MvNQw rhByUFgBSZ00dURrqU33HP/Rn3pTOT6Qct0tq2oGaAv8dNMYmpEF0esgHxWaz91wkeYq nE1vzq5zS8f8sof/e7eRDAvZLr/vhNofwBJOJKZHYYZID8Rxc3/yG3IQ4Uw/BXvpotWH LEtw== X-Gm-Message-State: AOAM531M6UcmwKLvZ+PF2mRMrtlDhFvPq4kEnU0gQcv29Wsjr4w9DwCx 08B3jm13coCY8gK2H3sW2p2koE0dKXU2Ct/HOMU= X-Google-Smtp-Source: ABdhPJyxybDYGW3vg1XvqDSGhlUml78e24INE3xoaTOSJg2eyo1KNu3No4aEMDdq5X6EWaboOrOh/JcsRYNZ2D8qVkM= X-Received: by 2002:a05:6638:d46:: with SMTP id d6mr7582270jak.124.1605699319307; Wed, 18 Nov 2020 03:35:19 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 18 Nov 2020 12:35:08 +0100 Message-ID: To: Francis Pouatcha Cc: "txauth@ietf.org" , Dick Hardt , Tom Jones , Denis , Justin Richer Content-Type: multipart/alternative; boundary="0000000000008b23db05b4600104" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 18 Nov 2020 11:35:23 -0000 --0000000000008b23db05b4600104 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Would make sense, but not so easy as we rely heavily on HTTP. Hence the discussion about deep links and so on. An alternative might be provided by wasm/wasi (running a local sandbox on your phone, for your own AS), but it's really early stage. This also poses another question that Denis has put forward, i.e. how do we handle the multiple AS scenario (likely to occur then). Fabien On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha wrote: > We are drifting away from the original problem space. > > - My original mention was about the "POST" request, that subsumes that > the "AS" is a "Server". Designing a new protocol, we cannot afford thi= s > limitation. > - I just mentioned SIOP to show a known and closed example? Let us not > focus on the device local discovery scheme (like openid:) for now. > - As capability of holding private keys on user device evolves, > server-based issuing of token will be fading out giving way to device = local > generation of token. > > While designing GNAP, let us assume the AS-Role can be exercised on a use= r > device and design the protocol to honor that. > > Best regards, > /Francis > ------------------------------ > *From:* TXAuth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Sent:* Tuesday, November 17, 2020 1:28 PM > *To:* Tom Jones > *Cc:* Fabien Imbault ; Denis ; > GNAP Mailing List ; Justin Richer > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Got it. > > So web apps invoke a openid: deep link and hope there is an app to handle > the openid: scheme? ... and that it is the user's wallet rather than some > malware that has registered openid: on the mobile device? > > A native app can attempt to open a deep link associated with an app, and > will fail if the app is not there. If the app is there, it will be opened= , > so this can't be used to silently test if an app is present, but it does > allow a native app to provide an alternative experience if an app is not > present. I don't think this works with custom schemes ... and I don't kno= w > how it could work from a web app on the phone with the current Safari API= s. > > Apple warns against using custom schemes [1] ... but perhaps they can be > convinced to make openid: a managed scheme similar to mailto:, tel:, > sms:, facetime: ? > > [1] > https://developer.apple.com/documentation/xcode/allowing_apps_and_website= s_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app > > > =E1=90=A7 > > On Tue, Nov 17, 2020 at 10:06 AM Tom Jones > wrote: > > You are - that is not standard which is opeind:// > This is the one step that still needs to be optimized for SIOP to have > good UX. > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote: > > Hi Tom > > I watched your video (I watched at 2X speed) > > Looks like the employment website app that is using localhost:8765 to > communicate with the wallet. Am I correct? > > /Dick > =E1=90=A7 > > On Tue, Nov 17, 2020 at 9:46 AM Tom Jones > wrote: > > Well, here's a demo. Note that in this case the AS is not online all of > the time, so it is really implicit flow and the OIDC id-token comes from > the siop device directly. > (whether this is front-channel or back channel is no longer an interestin= g > question.) > Now if an always-on AS is required, that is possible, but probably beyond > the scope of this effort and would require something like an > agent-in-the-sky (with diamonds). > here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 > > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: > > Ultimately, in most situations like these in the real world, the hurdle > isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP > (client) needs to have some incentive to trust the assertions and identit= y > information that=E2=80=99s coming from the AS. The same is true for an RS= trusting > tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to do= that (which SSI > answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, > because it=E2=80=99s a hard question). > > Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on device=E2=80=9D > element. We=E2=80=99ve got the start of it more than OAuth2/OIDC have by = allowing > the bootstrap of the process from a starting call: the interaction and > continuation URIs handed back by the AS don=E2=80=99t need to be the same= URIs that > the client starts with, so just like SIOP the process can start in HTTP a= nd > potentially move to other communication channels. A major difference is > that we aren=E2=80=99t dependent on the assumption that the user will alw= ays be in > a browser at some stage, and so the whole raft of front-channel messages > that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an = opportunity to > more explicitly open up alternative communication channels here, and that= =E2=80=99s > something I=E2=80=99d like to see engineered, even if it=E2=80=99s an ext= ension. I=E2=80=99d love > to see a concrete proposal as to how that would work over specific > protocols, starting with what we=E2=80=99ve got today. > > =E2=80=94 Justin > > On Nov 17, 2020, at 12:03 PM, Fabien Imbault > wrote: > > Hi Denis, hi Francis, > > At some point integration with SSI (on the authentication side) will > probably occur, including amongst other possibilities SIOP (since they wo= rk > with OpenID a part of the work will probably be made easier). > > That being said, Denis is right. It's not an AS. Technically it's entirel= y > possible to rely on a decentralized wallet (for instance on your phone) a= nd > a centralized AS. I know of a few studies on how to decentralize the AS > itself (for instance > https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). > Maybe it exists, but I'm still looking for real scenarios (or even > architectures) where an AS is deployed directly on a phone, and under the > sole authority of the RO, while being compatible with the rest of the > world. > > Cheers, > Fabien > > On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: > > Hello Francis, > > See two comments in line. > > > B) Current Document > > Roles description shall not hold any assumption on the physical structure > of the party fulfilling the roles. > [FI] not sure what you mean > > [FP] for example, we assume the AS is a server! In most SSI based use > cases, the AS will be running on the user device. See SIOP ( > https://identity.foundation/did-siop/). > > I browsed through the two drafts, i.e. : > > - Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, > and representations W3C Working Draft 08 November 2020 > - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working > Group Draft > > At no place within these two documents, it is possible to imagine that > "the AS will be running on the user device". > > From section 3 of the DIF Working Group Draft: > > "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the > SIOP will not return an access token to the RP". > > An Identity Wallet is not an AS. > > > Roles: > -> grant endpoint of the AS: Why is this a post request? This eliminates > the chance of having user device hosted AS (no server). > [FI] what would you propose instead? > Would also be interested to understand better the deployment model when > there is no server. That's something that was discussed several times but > I'm still missing the underlying architecture and use case. > > [FP] See above (SIOP). There will be a lot of identity wallets operated > on end user device. > > See the above comment. Please, do not confuse an Identity Wallet with an > Authentication Server (AS). > > Denis > > > -> Resource Owner (RO) : Authorizes the request? Does it authorize the > request or the access to a resource? > [FI] yes, we should make the wording clearer > > Missing Section Interactions: > --> This section shall introduce the notion of interaction before we star= t > listing interaction types. > [FI] yes > > Interaction Types: > --> I prefer a classification with Redirect, Decoupled and Embedded is. I= n > the draft, we have one redirect and 2 decouple interactions and nothing > else. > [FI] this should be handled as a specific discussion item. As a reminder, > how would you define embedded? > > In practice there's at least these modes: > - redirect and redirect back > - redirect to different browser or device > - user code > - CIBA > > [FP] This classification is limited. > > - Redirect: same device, same or different user agents (browser, > mobile app, desktop app, ...) > - Decoupled: different devices > - Embedded : RC carries RO authorization to AS > > > > Resource Access Request vs. Resource Request > --> Both are mixed up. No clarification of the context of each section. > [FI] could you clarify what you'd expect. Btw on this topic, there's a > more general discussion on whether we should make a distinction or not. > > =E2=80=8B[FP]: Here: > > - Resource Access Request: Requesting Access to a resource. Response > is an access token (or any type of grant) > - Resource Request: Request the resource. Response is the resource (or > a corresponding execution) > > > Token Content Negotiation > --> Not expressed as such. This is central to GNAP and not represented > enough in the document. > [FI] right. This should be a specific discussion item. > > Requesting "User" Information > we identify two types of users: RQ and RO. It will be better not to refer > to a user in this draft, but either to a RQ or an RO. > [FI] yes that would avoid potential misunderstandings. Although in the > end, people will translate RQ into user or end-user most of the time. Cf = in > definition, currently we have Requesting Party (RQ, aka "user") > > > Interaction Again > -> For each interaction type, we will have to describe the protocol flow > and the nature and behavior of involved Roles (Parties), Elements, Reques= ts. > [FI] yes > > > [FP] Will these and into tickets? > > Best regards. > /Francis > > > > -- > 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 > > --0000000000008b23db05b4600104 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An = alternative might be provided by wasm/wasi (running a local sandbox on your= phone, for your own AS), but it's really early stage. This also poses = another question that Denis has put forward, i.e. how do we handle the mult= iple AS scenario (likely to occur then).=C2=A0

Fab= ien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
Fro= m: TXAuth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>=
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; GNAP = Mailing List <txaut= h@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@g= mail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com>= wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gm= ail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be/Tq4= hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote= :
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> w= rote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.iet= f.org/html/draft-hardjono-oauth-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possible to imagine that &= quot;the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code = Flow as per [OIDC.Core], the SIOP will not return an access token to the RP= ".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity Wallet with an= Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
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
--0000000000008b23db05b4600104-- From nobody Wed Nov 18 04:06: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 1C20D3A17F8 for ; Wed, 18 Nov 2020 04:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" 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 w4Hk6_g-r-i2 for ; Wed, 18 Nov 2020 04:06:55 -0800 (PST) Received: from DEU01-BE0-obe.outbound.protection.outlook.com (mail-be0deu01on2135.outbound.protection.outlook.com [40.107.127.135]) (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 C80713A17F3 for ; Wed, 18 Nov 2020 04:06:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Igq0qlc7YCeE1G72tvDfu8RhljzVWZl+fpiNw4r83V+BFhbywsDAWr5ZcDfgTL9G1AOAyh58AjsMcU0Ug/VLGSLU03vi8HurzcB38EmYt6Qu3fjPk4oNqTQiAT4uC5Mai0B5w0pb46lEQRfgRwW3vGSNHYcbv4s2ubWH822ctCKx/kKTfq7F3COstOeexiHETs53bNcRITX4Ds/AljMbgg0KKXLbjj/fH8myLmZETHt7COHt8eQ+iIWPzLBttBK1orldem+sn2AJggmM2nUTUTYgt7hhGyneEVj6qOOhqx4ZP0ZHMF3zDqI+dHdzUT0FzSJvspbATk5QttLeF4R0og== 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=KmvL3+FnLRfkWT5ZdyLhuPbW8aRbRrdtcrxkOAUvg0E=; b=N99Y3VE+AIeUWdrTEybSlzrTJ70LYZNrLke0Y7/VquCvxIAnG4D52obTjsQvfBpObuXyr7TLxy9cuyrrSPmUyUdcMsPwwrH1C8XCPhS7umj4Xsms/He5ct6jpYM/2njoNS2VRRa5QNS61R2Y+xzGmRXIbby75dXU+3SDNsiCapzTPZZcuqSO5n0ZQKKDgZchcQhEBoPwptwTW/LdzNcFXmhL8QHb7HDu1yra38xD+HahVqqGeElIMuzoRpaMKybxWQ0ndWyUdbuzsooMnVpseJ/43DcGK7b324bWOR4+Nv4JKwTdgPGYg245sKaRGTdnlXHMK7OR+X0mcCWE06GZoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=adorsys.de; dmarc=pass action=none header.from=adorsys.de; dkim=pass header.d=adorsys.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KmvL3+FnLRfkWT5ZdyLhuPbW8aRbRrdtcrxkOAUvg0E=; b=xPv7hP96C/tHO5jAoooNKbybsOPeEHiXxUM2dqnwfgwPVkUJpvON7bhtg5odcqEcOkjrVaILW3JUGn/DPYzAVwSUovJproc4LbKjm0vgJswfU5mKT80plRlDKvZqxKA+TMHiDli1l8mDLfVYgk0KL430d5MiEcXqi6PNz5voMoVQB+gIrnKgnR9nxH5wSFZNxG2wnEw+wJErvktnAKeiqQMguvBeqMRjekAJ/70esKJao/ybr+AXsQ9Jsfk2g9OnQOauF7TmpNdScuInf9jAehMCCpenBioTVDE8oCZccnhg1ZE5rWrcm7RyGZwxsorYkqTSFG78Jt7hTw9jczfLSg== Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:11::11) by FR2P281MB0265.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:b::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.15; Wed, 18 Nov 2020 12:06:51 +0000 Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::b06b:117e:61f0:138b]) by FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::b06b:117e:61f0:138b%3]) with mapi id 15.20.3589.021; Wed, 18 Nov 2020 12:06:51 +0000 From: Francis Pouatcha To: Fabien Imbault , Francis Pouatcha CC: "txauth@ietf.org" , Dick Hardt , Tom Jones , Denis , Justin Richer Thread-Topic: [GNAP] Review of draft-ietf-gnap-core-protocol-00 Thread-Index: AQHWsiy3H8is1hHc2keFJtXpCHRvoKnGFMOAgATzTCaAAZWSAIAABTGAgAAETgCAAAeTAIAAA4oAgAACAwCAAAZDgIABFPt3gAAJ5ACAAAKPuQ== Date: Wed, 18 Nov 2020 12:06:51 +0000 Message-ID: References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=adorsys.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [65.33.157.159] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5be405ba-6f8a-4acf-f65f-08d88bba6f25 x-ms-traffictypediagnostic: FR2P281MB0265: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: D88W7MZ4KwKmnreRjQk9AgHan7WNyfp6706GIdJERkH2Rt8pgvbRIo1ERCyrDH3URsZdY5QpE4mAytRa2HZQGocymYfIUlaF2uEPmw1ScgTjqBrrqGvkfwFfu6032iRO+6EejUc2dfFI8s+FxC5AaivYZsLX2FbPKqDetajAtnE+7qy78BgkFaxU8H4ISUPRvua6Yv0uBt/Dwm9oRN1z+qQbrxAOmOBnISg2PMQWJGrpiDa+1nUWGIYUi9Ocskyo/lqhbyYvkiqtBPwJzpbeHjkeuddGUE2kiCTw2+1EWehkyw1KPx5m/ogeUr1uzXjkXCng2eAPkxZKUKzOq6txy+tvO4JrMsMQ6YN34rIFT2dLNSLL6rymoVZu6Pm9HBcK9pxf66BVA7o+erq1ylcJzfKK1p1WJ4eAM80WbiSyB5oHcWgPzMVjvjaxpbHGhWi5ZOvgjHMNIpSR8jlRi+GgcKs4QUnOcAz5Jj5gY5m+cuA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(39830400003)(396003)(376002)(346002)(136003)(8936002)(966005)(76116006)(478600001)(7696005)(8676002)(316002)(5660300002)(19627405001)(6506007)(53546011)(91956017)(66946007)(66476007)(64756008)(66446008)(33656002)(26005)(66556008)(86362001)(66574015)(166002)(186003)(83380400001)(110136005)(9686003)(54906003)(2906002)(4326008)(55016002)(71200400001)(30864003)(52536014)(99710200001)(15866825006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: GCogpoXgY/23N4sGkvjVDcAX95HAQctZfc1Xuq13QHU8TFM8L4DJe+2MTgxC+yaFgZ/DL0nWtuMmTTpD91qY1PJNXasHv9WERxRFN1zV2o/0JSEr9krM0cR5hPRamQv9pCRVo0nMXwGLPYbyTux2Xr7nj5mAjqGDi1EeUrktAi/LouXXlbakdLU8GZVFWsX/7Os7wxGtBOJEOjuDNvv8qLO56beqpBUtfd2m81Y1QwDGs5Fr9IcBZgE+fm3/+kRCn+QjzKTbITbZplLYL44k14bilvFZ+etKgW5tgEQK1wEc55JIj72eylqhd8Nxb6j4PAyKlcH8lWQAL/J7pO1jCxpgQc2rP2IX/dQuzstaX4D+iM5VKcfle0kiJInOFsNrwNZWvJUNasurZBr5yDzKFpzcywr7+ZZhARyPBpxcV8x+Lfe3jOsGaay/W/jQ3mHy/VnjYG+pcth3Ud5VEQDkWSvFRZmEIJgGS/aNYEeWcvxpBNqRb9DMTvsO6GiiCDUVrm4zA7Nb5jGa3YlS/zqk9yQzew6yOLoF91cgJNugvu1fBgbyVTHeXOjAEwZl2udXdPrBetJX1+QlX2jzvvHP0wjX5pXxmitw+zdCWijZWVIKzjQTD/EyEMUjgB3L+3TvYC4f+VsjocBLGxOM7ngeceokdZgGH+y1mEdYxQvZhLBOwy0iQWazpqhe0g6biEp0MMeb35LdMbXBoUv1qGn64m7muvdORbrtEp5CVXUU+d+RTno4kI5jjsHK8OeK88hcNu+qvr0CXJi3XmHBg+xQdQ== Content-Type: multipart/alternative; boundary="_000_FR2P281MB0106245AD7828040C4BF0F7E8DE10FR2P281MB0106DEUP_" MIME-Version: 1.0 X-OriginatorOrg: adorsys.de X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 5be405ba-6f8a-4acf-f65f-08d88bba6f25 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2020 12:06:51.6677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5e2c5484-e522-479d-91ca-515d6e0ce228 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ULwqdaeQM5mm0TY7Ca9cUcfF4ACBL8tnKeLq1bG+oIy97/W0U83E1q+A9v07oeIaQGcODX9s8utPEystHCzoSsDyn4Qt2/+/IxdH0vawkcs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0265 Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 18 Nov 2020 12:06:58 -0000 --_000_FR2P281MB0106245AD7828040C4BF0F7E8DE10FR2P281MB0106DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgd291bGQgYmUgbmljZSBpZiB0aGUgcHJvdG9jb2wgd2FzIGRlc2lnbmVkIGF0IG1hbnkgbGF5 ZXJzIG9mIGFic3RyYWN0aW9uLg0KDQoNCiAgKiAgIFRoZSBmaXJzdCBsYXllciBzaGFsbCBkZXNp Z24gYWJzdHJhY3QgcHJvdG9jb2wgZmxvd3MsIHdpdGhvdXQgc3BlY2lmaWNhdGlvbiBvZiB0aGUg bW9kZSBhbmQgbWVjaGFuaXNtIG9mIGludGVyYWN0aW9uLg0KICAqICAgVGhlIHNlY29uZCBsYXll ciBjYW4gaW5zdGFudGlhdGUgdGhlIGZpcnN0IGxheWVyIGZvciBkZWRpY2F0ZWQgaW50ZXJhY3Rp b24uIEhlcmUgd2UgY2FuIHRhbGsgaHR0cCwgd2UgY2FuIGRlZmluZSBpbnRlcmFjdGlvbnMgdGhh dCBwcmVzdW1lIHNlcnZlciBiYXNlZCB0b2tlbiBnZW5lcmF0aW9uLCB3ZSBjYW4gZGVmaW5lIGlu dGVyYWN0aW9uIHRoYXQgcnVuIG9uIHVzZXIgZGV2aWNlIGJhc2VkIHRva2VuIGdlbmVyYXRpb24u DQoNClRoaXMgaXMgYWxzbyB0aGUgZnVuZGFtZW50IG9mIHRoZSBzdHJ1Y3R1cmUgSSBwcm9wb3Nl ZCBmb3IgdGhlIHNwZWMgKGh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWduYXAvZ25hcC1jb3Jl LXByb3RvY29sL2lzc3Vlcy8zMCkuDQoNCi9GcmFuY2lzDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpGcm9tOiBGYWJpZW4gSW1iYXVsdCA8ZmFiaWVuLmltYmF1bHRAZ21haWwu Y29tPg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxOCwgMjAyMCA2OjM1IEFNDQpUbzogRnJh bmNpcyBQb3VhdGNoYSA8ZnBvQGFkb3JzeXMuZGU+DQpDYzogdHhhdXRoQGlldGYub3JnIDx0eGF1 dGhAaWV0Zi5vcmc+OyBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT47IFRvbSBKb25l cyA8dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbT47IERlbmlzIDxkZW5pcy5pZXRmQGZyZWUu ZnI+OyBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQpTdWJqZWN0OiBSZTogW0dOQVBd IFJldmlldyBvZiBkcmFmdC1pZXRmLWduYXAtY29yZS1wcm90b2NvbC0wMA0KDQpXb3VsZCBtYWtl IHNlbnNlLCBidXQgbm90IHNvIGVhc3kgYXMgd2UgcmVseSBoZWF2aWx5IG9uIEhUVFAuIEhlbmNl IHRoZSBkaXNjdXNzaW9uIGFib3V0IGRlZXAgbGlua3MgYW5kIHNvIG9uLg0KDQpBbiBhbHRlcm5h dGl2ZSBtaWdodCBiZSBwcm92aWRlZCBieSB3YXNtL3dhc2kgKHJ1bm5pbmcgYSBsb2NhbCBzYW5k Ym94IG9uIHlvdXIgcGhvbmUsIGZvciB5b3VyIG93biBBUyksIGJ1dCBpdCdzIHJlYWxseSBlYXJs eSBzdGFnZS4gVGhpcyBhbHNvIHBvc2VzIGFub3RoZXIgcXVlc3Rpb24gdGhhdCBEZW5pcyBoYXMg cHV0IGZvcndhcmQsIGkuZS4gaG93IGRvIHdlIGhhbmRsZSB0aGUgbXVsdGlwbGUgQVMgc2NlbmFy aW8gKGxpa2VseSB0byBvY2N1ciB0aGVuKS4NCg0KRmFiaWVuDQoNCk9uIFdlZCwgTm92IDE4LCAy MDIwIGF0IDEyOjE2IFBNIEZyYW5jaXMgUG91YXRjaGEgPGZwb0BhZG9yc3lzLmRlPG1haWx0bzpm cG9AYWRvcnN5cy5kZT4+IHdyb3RlOg0KV2UgYXJlIGRyaWZ0aW5nIGF3YXkgZnJvbSB0aGUgb3Jp Z2luYWwgcHJvYmxlbSBzcGFjZS4NCg0KICAqICAgTXkgb3JpZ2luYWwgbWVudGlvbiB3YXMgYWJv dXQgdGhlICJQT1NUIiByZXF1ZXN0LCB0aGF0IHN1YnN1bWVzIHRoYXQgdGhlICJBUyIgaXMgYSAi U2VydmVyIi4gRGVzaWduaW5nIGEgbmV3IHByb3RvY29sLCB3ZSBjYW5ub3QgYWZmb3JkIHRoaXMg bGltaXRhdGlvbi4NCiAgKiAgIEkganVzdCBtZW50aW9uZWQgU0lPUCB0byBzaG93IGEga25vd24g YW5kIGNsb3NlZCBleGFtcGxlPyBMZXQgdXMgbm90IGZvY3VzIG9uIHRoZSBkZXZpY2UgbG9jYWwg ZGlzY292ZXJ5IHNjaGVtZSAobGlrZSBvcGVuaWQ6KSBmb3Igbm93Lg0KICAqICAgQXMgY2FwYWJp bGl0eSBvZiBob2xkaW5nIHByaXZhdGUga2V5cyBvbiB1c2VyIGRldmljZSBldm9sdmVzLCBzZXJ2 ZXItYmFzZWQgaXNzdWluZyBvZiB0b2tlbiB3aWxsIGJlIGZhZGluZyBvdXQgZ2l2aW5nIHdheSB0 byBkZXZpY2UgbG9jYWwgZ2VuZXJhdGlvbiBvZiB0b2tlbi4NCg0KV2hpbGUgZGVzaWduaW5nIEdO QVAsIGxldCB1cyBhc3N1bWUgdGhlIEFTLVJvbGUgY2FuIGJlIGV4ZXJjaXNlZCBvbiBhIHVzZXIg ZGV2aWNlIGFuZCBkZXNpZ24gdGhlIHByb3RvY29sIHRvIGhvbm9yIHRoYXQuDQoNCkJlc3QgcmVn YXJkcywNCi9GcmFuY2lzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTog VFhBdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0 Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFp bHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE3LCAy MDIwIDE6MjggUE0NClRvOiBUb20gSm9uZXMgPHRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb208 bWFpbHRvOnRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb20+Pg0KQ2M6IEZhYmllbiBJbWJhdWx0 IDxmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208bWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNv bT4+OyBEZW5pcyA8ZGVuaXMuaWV0ZkBmcmVlLmZyPG1haWx0bzpkZW5pcy5pZXRmQGZyZWUuZnI+ PjsgR05BUCBNYWlsaW5nIExpc3QgPHR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYu b3JnPj47IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQu ZWR1Pj4NClN1YmplY3Q6IFJlOiBbR05BUF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtZ25hcC1jb3Jl LXByb3RvY29sLTAwDQoNCkdvdCBpdC4NCg0KU28gd2ViIGFwcHMgaW52b2tlIGEgb3BlbmlkOiBk ZWVwIGxpbmsgYW5kIGhvcGUgdGhlcmUgaXMgYW4gYXBwIHRvIGhhbmRsZSB0aGUgb3BlbmlkOiBz Y2hlbWU/IC4uLiBhbmQgdGhhdCBpdCBpcyB0aGUgdXNlcidzIHdhbGxldCByYXRoZXIgdGhhbiBz b21lIG1hbHdhcmUgdGhhdCBoYXMgcmVnaXN0ZXJlZCBvcGVuaWQ6IG9uIHRoZSBtb2JpbGUgZGV2 aWNlPw0KDQpBIG5hdGl2ZSBhcHAgY2FuIGF0dGVtcHQgdG8gb3BlbiBhIGRlZXAgbGluayBhc3Nv Y2lhdGVkIHdpdGggYW4gYXBwLCBhbmQgd2lsbCBmYWlsIGlmIHRoZSBhcHAgaXMgbm90IHRoZXJl LiBJZiB0aGUgYXBwIGlzIHRoZXJlLCBpdCB3aWxsIGJlIG9wZW5lZCwgc28gdGhpcyBjYW4ndCBi ZSB1c2VkIHRvIHNpbGVudGx5IHRlc3QgaWYgYW4gYXBwIGlzIHByZXNlbnQsIGJ1dCBpdCBkb2Vz IGFsbG93IGEgbmF0aXZlIGFwcCB0byBwcm92aWRlIGFuIGFsdGVybmF0aXZlIGV4cGVyaWVuY2Ug aWYgYW4gYXBwIGlzIG5vdCBwcmVzZW50LiBJIGRvbid0IHRoaW5rIHRoaXMgd29ya3Mgd2l0aCBj dXN0b20gc2NoZW1lcyAuLi4gYW5kIEkgZG9uJ3Qga25vdyBob3cgaXQgY291bGQgd29yayBmcm9t IGEgd2ViIGFwcCBvbiB0aGUgcGhvbmUgd2l0aCB0aGUgY3VycmVudCBTYWZhcmkgQVBJcy4NCg0K QXBwbGUgd2FybnMgYWdhaW5zdCB1c2luZyBjdXN0b20gc2NoZW1lcyBbMV0gLi4uIGJ1dCBwZXJo YXBzIHRoZXkgY2FuIGJlIGNvbnZpbmNlZCB0byBtYWtlIG9wZW5pZDogYSBtYW5hZ2VkIHNjaGVt ZSBzaW1pbGFyIHRvIG1haWx0bzosIHRlbDosIHNtczosIGZhY2V0aW1lOiA/DQoNClsxXSBodHRw czovL2RldmVsb3Blci5hcHBsZS5jb20vZG9jdW1lbnRhdGlvbi94Y29kZS9hbGxvd2luZ19hcHBz X2FuZF93ZWJzaXRlc190b19saW5rX3RvX3lvdXJfY29udGVudC9kZWZpbmluZ19hX2N1c3RvbV91 cmxfc2NoZW1lX2Zvcl95b3VyX2FwcA0KDQoNCltodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5j b20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250 ZW50Jmd1aWQ9MDExNDkwYmUtZDNhMC00YjJjLThhYmItZTUxMTc1ZTNhZTE5XeGQpw0KDQpPbiBU dWUsIE5vdiAxNywgMjAyMCBhdCAxMDowNiBBTSBUb20gSm9uZXMgPHRob21hc2NsaW5nYW5qb25l c0BnbWFpbC5jb208bWFpbHRvOnRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb20+PiB3cm90ZToN CllvdSBhcmUgLSB0aGF0IGlzIG5vdCBzdGFuZGFyZCB3aGljaCBpcyBvcGVpbmQ6Ly8NClRoaXMg aXMgdGhlIG9uZSBzdGVwIHRoYXQgc3RpbGwgbmVlZHMgdG8gYmUgb3B0aW1pemVkIGZvciBTSU9Q IHRvIGhhdmUgZ29vZCBVWC4NClBlYWNlIC4udG9tDQoNCg0KT24gVHVlLCBOb3YgMTcsIDIwMjAg YXQgOTo1OSBBTSBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5o YXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCkhpIFRvbQ0KDQpJIHdhdGNoZWQgeW91ciB2aWRlbyAo SSB3YXRjaGVkIGF0IDJYIHNwZWVkKQ0KDQpMb29rcyBsaWtlIHRoZSBlbXBsb3ltZW50IHdlYnNp dGUgYXBwIHRoYXQgaXMgdXNpbmcgbG9jYWxob3N0Ojg3NjUgdG8gY29tbXVuaWNhdGUgd2l0aCB0 aGUgd2FsbGV0LiBBbSBJIGNvcnJlY3Q/DQoNCi9EaWNrDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFw cHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16 ZXJvY29udGVudCZndWlkPTExYTYyY2U2LTliNGEtNGQ1Zi04NmM1LWQyYzExNDM5NWFlZV3hkKcN Cg0KT24gVHVlLCBOb3YgMTcsIDIwMjAgYXQgOTo0NiBBTSBUb20gSm9uZXMgPHRob21hc2NsaW5n YW5qb25lc0BnbWFpbC5jb208bWFpbHRvOnRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb20+PiB3 cm90ZToNCldlbGwsIGhlcmUncyBhIGRlbW8uIE5vdGUgdGhhdCBpbiB0aGlzIGNhc2UgdGhlIEFT IGlzIG5vdCBvbmxpbmUgYWxsIG9mIHRoZSB0aW1lLCBzbyBpdCBpcyByZWFsbHkgaW1wbGljaXQg ZmxvdyBhbmQgdGhlIE9JREMgaWQtdG9rZW4gY29tZXMgZnJvbSB0aGUgc2lvcCBkZXZpY2UgZGly ZWN0bHkuDQood2hldGhlciB0aGlzIGlzIGZyb250LWNoYW5uZWwgb3IgYmFjayBjaGFubmVsIGlz IG5vIGxvbmdlciBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbi4pDQpOb3cgaWYgYW4gYWx3YXlzLW9u IEFTIGlzIHJlcXVpcmVkLCB0aGF0IGlzIHBvc3NpYmxlLCBidXQgcHJvYmFibHkgYmV5b25kIHRo ZSBzY29wZSBvZiB0aGlzIGVmZm9ydCBhbmQgd291bGQgcmVxdWlyZSBzb21ldGhpbmcgbGlrZSBh biBhZ2VudC1pbi10aGUtc2t5ICh3aXRoIGRpYW1vbmRzKS4NCmhlcmUgaXMgdGhlIGxpbmsgdG8g dGhlIDkgbWluIHZpZGVvICAgaHR0cHM6Ly95b3V0dS5iZS9UcTRodzdYNVNXMDxodHRwczovL3Vy bGRlZmVuc2UudXMvdjIvdXJsP3U9aHR0cHMtM0FfX3lvdXR1LmJlX1RxNGh3N1g1U1cwJmQ9RHdN RmFRJmM9MnBsSTNoWEg4d3czajJnOHBWMTlRSElmNFNtS19JLUVvbF9wOVAwQ3R0RSZyPUQ1bG5m b2EyTVZaV0VMcVZiYno3MW9vZWxiUDdyVkdDakdEU0JOdlVwWVEmbT1peHN1ZEdTcl9kaEctU0xp YXRiNFN6OUZXc2xteXduWXlaQU9MZ1p4aGw4JnM9amRMTHkwRzFKVFFDQU9CWjZQZVVnSTBraUN0 VkpYcnJ1MFZUb1lXbE5aOCZlPT4NClBlYWNlIC4udG9tDQoNCg0KT24gVHVlLCBOb3YgMTcsIDIw MjAgYXQgOToyMCBBTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNo ZXJAbWl0LmVkdT4+IHdyb3RlOg0KVWx0aW1hdGVseSwgaW4gbW9zdCBzaXR1YXRpb25zIGxpa2Ug dGhlc2UgaW4gdGhlIHJlYWwgd29ybGQsIHRoZSBodXJkbGUgaXNu4oCZdCB0ZWNobmljYWwgY29t cGF0aWJpbGl0eSBzbyBtdWNoIGFzIGl0IGlzIHRydXN0IGNvbXBhdGliaWxpdHkuIFRoZSBSUCAo Y2xpZW50KSBuZWVkcyB0byBoYXZlIHNvbWUgaW5jZW50aXZlIHRvIHRydXN0IHRoZSBhc3NlcnRp b25zIGFuZCBpZGVudGl0eSBpbmZvcm1hdGlvbiB0aGF04oCZcyBjb21pbmcgZnJvbSB0aGUgQVMu IFRoZSBzYW1lIGlzIHRydWUgZm9yIGFuIFJTIHRydXN0aW5nIHRva2VucyBmcm9tIHRoZSBBUy4g VGhlIGhhcmQgcXVlc3Rpb24gaXMgbGVzcyDigJxob3figJ0gdG8gZG8gdGhhdCAod2hpY2ggU1NJ IGFuc3dlcnMpLCBidXQgbW9yZSDigJx3aHnigJ0gdG8gZG8gdGhhdCAod2hpY2ggU1NJIGRvZXNu 4oCZdCBhbnN3ZXIgdmVyeSB3ZWxsLCBiZWNhdXNlIGl04oCZcyBhIGhhcmQgcXVlc3Rpb24pLg0K DQpTdGlsbDogaXTigJlzIGRlZmluaXRlbHkgYSBxdWVzdGlvbiBhYm91dCBob3cgdG8gc3VwcG9y dCB0aGlzIOKAnEFTIG9uIGRldmljZeKAnSBlbGVtZW50LiBXZeKAmXZlIGdvdCB0aGUgc3RhcnQg b2YgaXQgbW9yZSB0aGFuIE9BdXRoMi9PSURDIGhhdmUgYnkgYWxsb3dpbmcgdGhlIGJvb3RzdHJh cCBvZiB0aGUgcHJvY2VzcyBmcm9tIGEgc3RhcnRpbmcgY2FsbDogdGhlIGludGVyYWN0aW9uIGFu ZCBjb250aW51YXRpb24gVVJJcyBoYW5kZWQgYmFjayBieSB0aGUgQVMgZG9u4oCZdCBuZWVkIHRv IGJlIHRoZSBzYW1lIFVSSXMgdGhhdCB0aGUgY2xpZW50IHN0YXJ0cyB3aXRoLCBzbyBqdXN0IGxp a2UgU0lPUCB0aGUgcHJvY2VzcyBjYW4gc3RhcnQgaW4gSFRUUCBhbmQgcG90ZW50aWFsbHkgbW92 ZSB0byBvdGhlciBjb21tdW5pY2F0aW9uIGNoYW5uZWxzLiBBIG1ham9yIGRpZmZlcmVuY2UgaXMg dGhhdCB3ZSBhcmVu4oCZdCBkZXBlbmRlbnQgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgdXNl ciB3aWxsIGFsd2F5cyBiZSBpbiBhIGJyb3dzZXIgYXQgc29tZSBzdGFnZSwgYW5kIHNvIHRoZSB3 aG9sZSByYWZ0IG9mIGZyb250LWNoYW5uZWwgbWVzc2FnZXMgdGhhdCBTSU9QIHJlbGllcyBvbiBk b2VzbuKAmXQgZmx5LiBUaGF0IHNhaWQsIHdl4oCZdmUgZ290IGFuIG9wcG9ydHVuaXR5IHRvIG1v cmUgZXhwbGljaXRseSBvcGVuIHVwIGFsdGVybmF0aXZlIGNvbW11bmljYXRpb24gY2hhbm5lbHMg aGVyZSwgYW5kIHRoYXTigJlzIHNvbWV0aGluZyBJ4oCZZCBsaWtlIHRvIHNlZSBlbmdpbmVlcmVk LCBldmVuIGlmIGl04oCZcyBhbiBleHRlbnNpb24uIEnigJlkIGxvdmUgdG8gc2VlIGEgY29uY3Jl dGUgcHJvcG9zYWwgYXMgdG8gaG93IHRoYXQgd291bGQgd29yayBvdmVyIHNwZWNpZmljIHByb3Rv Y29scywgc3RhcnRpbmcgd2l0aCB3aGF0IHdl4oCZdmUgZ290IHRvZGF5Lg0KDQog4oCUIEp1c3Rp bg0KDQpPbiBOb3YgMTcsIDIwMjAsIGF0IDEyOjAzIFBNLCBGYWJpZW4gSW1iYXVsdCA8ZmFiaWVu LmltYmF1bHRAZ21haWwuY29tPG1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20+PiB3cm90 ZToNCg0KSGkgRGVuaXMsIGhpIEZyYW5jaXMsDQoNCkF0IHNvbWUgcG9pbnQgaW50ZWdyYXRpb24g d2l0aCBTU0kgKG9uIHRoZSBhdXRoZW50aWNhdGlvbiBzaWRlKSB3aWxsIHByb2JhYmx5IG9jY3Vy LCBpbmNsdWRpbmcgYW1vbmdzdCBvdGhlciBwb3NzaWJpbGl0aWVzIFNJT1AgKHNpbmNlIHRoZXkg d29yayB3aXRoIE9wZW5JRCBhIHBhcnQgb2YgdGhlIHdvcmsgd2lsbCBwcm9iYWJseSBiZSBtYWRl IGVhc2llcikuDQoNClRoYXQgYmVpbmcgc2FpZCwgRGVuaXMgaXMgcmlnaHQuIEl0J3Mgbm90IGFu IEFTLiBUZWNobmljYWxseSBpdCdzIGVudGlyZWx5IHBvc3NpYmxlIHRvIHJlbHkgb24gYSBkZWNl bnRyYWxpemVkIHdhbGxldCAoZm9yIGluc3RhbmNlIG9uIHlvdXIgcGhvbmUpIGFuZCBhIGNlbnRy YWxpemVkIEFTLiBJIGtub3cgb2YgYSBmZXcgc3R1ZGllcyBvbiBob3cgdG8gZGVjZW50cmFsaXpl IHRoZSBBUyBpdHNlbGYgKGZvciBpbnN0YW5jZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaGFyZGpvbm8tb2F1dGgtZGVjZW50cmFsaXplZC0wMikuDQpNYXliZSBpdCBleGlzdHMs IGJ1dCBJJ20gc3RpbGwgbG9va2luZyBmb3IgcmVhbCBzY2VuYXJpb3MgKG9yIGV2ZW4gYXJjaGl0 ZWN0dXJlcykgd2hlcmUgYW4gQVMgaXMgZGVwbG95ZWQgZGlyZWN0bHkgb24gYSBwaG9uZSwgYW5k IHVuZGVyIHRoZSBzb2xlIGF1dGhvcml0eSBvZiB0aGUgUk8sIHdoaWxlIGJlaW5nIGNvbXBhdGli bGUgd2l0aCB0aGUgcmVzdCBvZiB0aGUgd29ybGQuDQoNCkNoZWVycywNCkZhYmllbg0KDQpPbiBU dWUsIE5vdiAxNywgMjAyMCBhdCA1OjQ1IFBNIERlbmlzIDxkZW5pcy5pZXRmQGZyZWUuZnI8bWFp bHRvOmRlbmlzLmlldGZAZnJlZS5mcj4+IHdyb3RlOg0KSGVsbG8gIEZyYW5jaXMsDQoNClNlZSB0 d28gY29tbWVudHMgaW4gbGluZS4NCg0KDQpCKSBDdXJyZW50IERvY3VtZW50DQoNClJvbGVzIGRl c2NyaXB0aW9uIHNoYWxsIG5vdCBob2xkIGFueSBhc3N1bXB0aW9uIG9uIHRoZSBwaHlzaWNhbCBz dHJ1Y3R1cmUgb2YgdGhlIHBhcnR5IGZ1bGZpbGxpbmcgdGhlIHJvbGVzLg0KW0ZJXSBub3Qgc3Vy ZSB3aGF0IHlvdSBtZWFuDQogW0ZQXSBmb3IgZXhhbXBsZSwgd2UgYXNzdW1lIHRoZSBBUyBpcyBh IHNlcnZlciEgSW4gbW9zdCBTU0kgYmFzZWQgdXNlIGNhc2VzLCB0aGUgQVMgd2lsbCBiZSBydW5u aW5nIG9uIHRoZSB1c2VyIGRldmljZS4gU2VlIFNJT1AgKGh0dHBzOi8vaWRlbnRpdHkuZm91bmRh dGlvbi9kaWQtc2lvcC8pLg0KDQpJIGJyb3dzZWQgdGhyb3VnaCB0aGUgdHdvIGRyYWZ0cywgaS5l LiA6DQoNCiAgKiAgIERlY2VudHJhbGl6ZWQgSWRlbnRpZmllcnMgKERJRHMpIHYxLjAgQ29yZSBh cmNoaXRlY3R1cmUsIGRhdGEgbW9kZWwsIGFuZCByZXByZXNlbnRhdGlvbnMgVzNDIFdvcmtpbmcg RHJhZnQgMDggTm92ZW1iZXIgMjAyMA0KICAqICAgU2VsZi1Jc3N1ZWQgT3BlbklEIENvbm5lY3Qg UHJvdmlkZXIgRElEIFByb2ZpbGUgdjAuMS4gRElGIFdvcmtpbmcgR3JvdXAgRHJhZnQNCg0KQXQg bm8gcGxhY2Ugd2l0aGluIHRoZXNlIHR3byBkb2N1bWVudHMsIGl0IGlzIHBvc3NpYmxlIHRvIGlt YWdpbmUgdGhhdCAidGhlIEFTIHdpbGwgYmUgcnVubmluZyBvbiB0aGUgdXNlciBkZXZpY2UiLg0K DQpGcm9tIHNlY3Rpb24gMyBvZiB0aGUgRElGIFdvcmtpbmcgR3JvdXAgRHJhZnQ6DQoNCiAgICAg ICJVbmxpa2UgdGhlIE9JREMgQXV0aG9yaXphdGlvbiBDb2RlIEZsb3cgYXMgcGVyIFtPSURDLkNv cmVdLCB0aGUgU0lPUCB3aWxsIG5vdCByZXR1cm4gYW4gYWNjZXNzIHRva2VuIHRvIHRoZSBSUCIu DQoNCkFuIElkZW50aXR5IFdhbGxldCBpcyBub3QgYW4gQVMuDQoNClJvbGVzOg0KLT4gZ3JhbnQg ZW5kcG9pbnQgb2YgdGhlIEFTOiBXaHkgaXMgdGhpcyBhIHBvc3QgcmVxdWVzdD8gVGhpcyBlbGlt aW5hdGVzIHRoZSBjaGFuY2Ugb2YgaGF2aW5nIHVzZXIgZGV2aWNlIGhvc3RlZCBBUyAobm8gc2Vy dmVyKS4NCltGSV0gd2hhdCB3b3VsZCB5b3UgcHJvcG9zZSBpbnN0ZWFkPw0KV291bGQgYWxzbyBi ZSBpbnRlcmVzdGVkIHRvIHVuZGVyc3RhbmQgYmV0dGVyIHRoZSBkZXBsb3ltZW50IG1vZGVsIHdo ZW4gdGhlcmUgaXMgbm8gc2VydmVyLiBUaGF0J3Mgc29tZXRoaW5nIHRoYXQgd2FzIGRpc2N1c3Nl ZCBzZXZlcmFsIHRpbWVzIGJ1dCBJJ20gc3RpbGwgbWlzc2luZyB0aGUgdW5kZXJseWluZyBhcmNo aXRlY3R1cmUgYW5kIHVzZSBjYXNlLg0KIFtGUF0gU2VlIGFib3ZlIChTSU9QKS4gVGhlcmUgd2ls bCBiZSBhIGxvdCBvZiBpZGVudGl0eSB3YWxsZXRzIG9wZXJhdGVkIG9uIGVuZCB1c2VyIGRldmlj ZS4NCg0KU2VlIHRoZSBhYm92ZSBjb21tZW50LiBQbGVhc2UsIGRvIG5vdCBjb25mdXNlIGFuIElk ZW50aXR5IFdhbGxldCB3aXRoIGFuIEF1dGhlbnRpY2F0aW9uIFNlcnZlciAoQVMpLg0KDQpEZW5p cw0KDQotPiBSZXNvdXJjZSBPd25lciAoUk8pIDogQXV0aG9yaXplcyB0aGUgcmVxdWVzdD8gRG9l cyBpdCBhdXRob3JpemUgdGhlIHJlcXVlc3Qgb3IgdGhlIGFjY2VzcyB0byBhIHJlc291cmNlPw0K W0ZJXSB5ZXMsIHdlIHNob3VsZCBtYWtlIHRoZSB3b3JkaW5nIGNsZWFyZXINCg0KTWlzc2luZyBT ZWN0aW9uIEludGVyYWN0aW9uczoNCi0tPiBUaGlzIHNlY3Rpb24gc2hhbGwgaW50cm9kdWNlIHRo ZSBub3Rpb24gb2YgaW50ZXJhY3Rpb24gYmVmb3JlIHdlIHN0YXJ0IGxpc3RpbmcgaW50ZXJhY3Rp b24gdHlwZXMuDQpbRkldIHllcw0KDQpJbnRlcmFjdGlvbiBUeXBlczoNCi0tPiBJIHByZWZlciBh IGNsYXNzaWZpY2F0aW9uIHdpdGggUmVkaXJlY3QsIERlY291cGxlZCBhbmQgRW1iZWRkZWQgaXMu IEluIHRoZSBkcmFmdCwgd2UgaGF2ZSBvbmUgcmVkaXJlY3QgYW5kIDIgZGVjb3VwbGUgaW50ZXJh Y3Rpb25zIGFuZCBub3RoaW5nIGVsc2UuDQpbRkldIHRoaXMgc2hvdWxkIGJlIGhhbmRsZWQgYXMg YSBzcGVjaWZpYyBkaXNjdXNzaW9uIGl0ZW0uIEFzIGEgcmVtaW5kZXIsIGhvdyB3b3VsZCB5b3Ug ZGVmaW5lIGVtYmVkZGVkPw0KDQpJbiBwcmFjdGljZSB0aGVyZSdzIGF0IGxlYXN0IHRoZXNlIG1v ZGVzOg0KLSByZWRpcmVjdCBhbmQgcmVkaXJlY3QgYmFjaw0KLSByZWRpcmVjdCB0byBkaWZmZXJl bnQgYnJvd3NlciBvciBkZXZpY2UNCi0gdXNlciBjb2RlDQotIENJQkENCltGUF0gVGhpcyBjbGFz c2lmaWNhdGlvbiBpcyBsaW1pdGVkLg0KDQogICogICBSZWRpcmVjdDogc2FtZSBkZXZpY2UsIHNh bWUgb3IgZGlmZmVyZW50IHVzZXIgYWdlbnRzIChicm93c2VyLCBtb2JpbGUgYXBwLCBkZXNrdG9w IGFwcCwgLi4uKQ0KICAqICAgRGVjb3VwbGVkOiBkaWZmZXJlbnQgZGV2aWNlcw0KICAqICAgRW1i ZWRkZWQgOiBSQyBjYXJyaWVzIFJPIGF1dGhvcml6YXRpb24gdG8gQVMNCg0KDQpSZXNvdXJjZSBB Y2Nlc3MgUmVxdWVzdCB2cy4gUmVzb3VyY2UgUmVxdWVzdA0KLS0+IEJvdGggYXJlIG1peGVkIHVw LiBObyBjbGFyaWZpY2F0aW9uIG9mIHRoZSBjb250ZXh0IG9mIGVhY2ggc2VjdGlvbi4NCltGSV0g Y291bGQgeW91IGNsYXJpZnkgd2hhdCB5b3UnZCBleHBlY3QuICBCdHcgb24gdGhpcyB0b3BpYywg dGhlcmUncyBhIG1vcmUgZ2VuZXJhbCBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgd2Ugc2hvdWxkIG1h a2UgYSBkaXN0aW5jdGlvbiBvciBub3QuDQrigItbRlBdOiBIZXJlOg0KDQogICogICBSZXNvdXJj ZSBBY2Nlc3MgUmVxdWVzdDogUmVxdWVzdGluZyBBY2Nlc3MgdG8gYSByZXNvdXJjZS4gUmVzcG9u c2UgaXMgYW4gYWNjZXNzIHRva2VuIChvciBhbnkgdHlwZSBvZiBncmFudCkNCiAgKiAgIFJlc291 cmNlIFJlcXVlc3Q6IFJlcXVlc3QgdGhlIHJlc291cmNlLiBSZXNwb25zZSBpcyB0aGUgcmVzb3Vy Y2UgKG9yIGEgY29ycmVzcG9uZGluZyBleGVjdXRpb24pDQoNClRva2VuIENvbnRlbnQgTmVnb3Rp YXRpb24NCi0tPiBOb3QgZXhwcmVzc2VkIGFzIHN1Y2guIFRoaXMgaXMgY2VudHJhbCB0byBHTkFQ IGFuZCBub3QgcmVwcmVzZW50ZWQgZW5vdWdoICBpbiB0aGUgZG9jdW1lbnQuDQpbRkldIHJpZ2h0 LiBUaGlzIHNob3VsZCBiZSBhIHNwZWNpZmljIGRpc2N1c3Npb24gaXRlbS4NCg0KUmVxdWVzdGlu ZyAiVXNlciIgSW5mb3JtYXRpb24NCndlIGlkZW50aWZ5IHR3byB0eXBlcyBvZiB1c2VyczogUlEg YW5kIFJPLiBJdCB3aWxsIGJlIGJldHRlciBub3QgdG8gcmVmZXIgdG8gYSB1c2VyIGluIHRoaXMg ZHJhZnQsIGJ1dCBlaXRoZXIgdG8gYSBSUSBvciBhbiBSTy4NCltGSV0geWVzIHRoYXQgd291bGQg YXZvaWQgcG90ZW50aWFsIG1pc3VuZGVyc3RhbmRpbmdzLiBBbHRob3VnaCBpbiB0aGUgZW5kLCBw ZW9wbGUgd2lsbCB0cmFuc2xhdGUgUlEgaW50byB1c2VyIG9yIGVuZC11c2VyIG1vc3Qgb2YgdGhl IHRpbWUuIENmIGluIGRlZmluaXRpb24sIGN1cnJlbnRseSB3ZSBoYXZlIFJlcXVlc3RpbmcgUGFy dHkgKFJRLCBha2EgInVzZXIiKQ0KDQoNCkludGVyYWN0aW9uIEFnYWluDQotPiBGb3IgZWFjaCBp bnRlcmFjdGlvbiB0eXBlLCB3ZSB3aWxsIGhhdmUgdG8gZGVzY3JpYmUgdGhlIHByb3RvY29sIGZs b3cgYW5kIHRoZSBuYXR1cmUgYW5kIGJlaGF2aW9yIG9mIGludm9sdmVkIFJvbGVzIChQYXJ0aWVz KSwgRWxlbWVudHMsIFJlcXVlc3RzLg0KW0ZJXSB5ZXMNCg0KW0ZQXSBXaWxsIHRoZXNlIGFuZCBp bnRvIHRpY2tldHM/DQoNCkJlc3QgcmVnYXJkcy4NCi9GcmFuY2lzDQoNCg0KDQoNCg0KLS0NClRY QXV0aCBtYWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWlsdG86VFhBdXRoQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCi0tDQpUWEF1 dGggbWFpbGluZyBsaXN0DQpUWEF1dGhAaWV0Zi5vcmc8bWFpbHRvOlRYQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCi0tDQpUWEF1 dGggbWFpbGluZyBsaXN0DQpUWEF1dGhAaWV0Zi5vcmc8bWFpbHRvOlRYQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQotLQ0KVFhBdXRo IG1haWxpbmcgbGlzdA0KVFhBdXRoQGlldGYub3JnPG1haWx0bzpUWEF1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0K --_000_FR2P281MB0106245AD7828040C4BF0F7E8DE10FR2P281MB0106DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkl0IHdvdWxkIGJlIG5pY2UgaWYgdGhlIHByb3RvY29sIHdh cyBkZXNpZ25lZCBhdCBtYW55IGxheWVycyBvZiBhYnN0cmFjdGlvbi48L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPHVsPg0KPGxpPlRo ZSBmaXJzdCBsYXllciBzaGFsbCBkZXNpZ24gYWJzdHJhY3QgcHJvdG9jb2wgZmxvd3MsIHdpdGhv dXQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgbW9kZSBhbmQgbWVjaGFuaXNtIG9mIGludGVyYWN0aW9u LjwvbGk+PGxpPlRoZSBzZWNvbmQgbGF5ZXIgY2FuIGluc3RhbnRpYXRlIHRoZSBmaXJzdCBsYXll ciBmb3IgZGVkaWNhdGVkIGludGVyYWN0aW9uLiBIZXJlIHdlIGNhbiB0YWxrIGh0dHAsIHdlIGNh biBkZWZpbmUgaW50ZXJhY3Rpb25zIHRoYXQgcHJlc3VtZSBzZXJ2ZXIgYmFzZWQgdG9rZW4gZ2Vu ZXJhdGlvbiwgd2UgY2FuIGRlZmluZSBpbnRlcmFjdGlvbiB0aGF0IHJ1biBvbiB1c2VyIGRldmlj ZSBiYXNlZCB0b2tlbiBnZW5lcmF0aW9uLjwvbGk+PC91bD4NCjxkaXY+VGhpcyBpcyBhbHNvIHRo ZSBmdW5kYW1lbnQgb2YgdGhlIHN0cnVjdHVyZSBJIHByb3Bvc2VkIGZvciB0aGUgc3BlYyAoPGEg aHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctZ25hcC9nbmFwLWNvcmUtcHJvdG9jb2wv aXNzdWVzLzMwIiBpZD0iTFBsbmszMzgzOTEiPmh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWdu YXAvZ25hcC1jb3JlLXByb3RvY29sL2lzc3Vlcy8zMDwvYT4pLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+L0ZyYW5jaXM8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0iYXBwZW5kb25zZW5k Ij48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNh LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4NCjxicj4NCjwv ZGl2Pg0KPGhyIHRhYmluZGV4PSItMSIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJsb2NrOyB3aWR0 aDo5OCUiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyIgZGlyPSJsdHIiPjxmb250IGZhY2U9IkNh bGlicmksIHNhbnMtc2VyaWYiIGNvbG9yPSIjMDAwMDAwIiBzdHlsZT0iZm9udC1zaXplOjExcHQi PjxiPkZyb206PC9iPiBGYWJpZW4gSW1iYXVsdCAmbHQ7ZmFiaWVuLmltYmF1bHRAZ21haWwuY29t Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDE4LCAyMDIwIDY6MzUg QU08YnI+DQo8Yj5Ubzo8L2I+IEZyYW5jaXMgUG91YXRjaGEgJmx0O2Zwb0BhZG9yc3lzLmRlJmd0 Ozxicj4NCjxiPkNjOjwvYj4gdHhhdXRoQGlldGYub3JnICZsdDt0eGF1dGhAaWV0Zi5vcmcmZ3Q7 OyBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs7IFRvbSBKb25lcyAmbHQ7 dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbSZndDs7IERlbmlzICZsdDtkZW5pcy5pZXRmQGZy ZWUuZnImZ3Q7OyBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbR05BUF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtZ25hcC1jb3JlLXBy b3RvY29sLTAwPC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg ZGlyPSJsdHIiPldvdWxkIG1ha2Ugc2Vuc2UsIGJ1dCBub3Qgc28gZWFzeSBhcyB3ZSByZWx5IGhl YXZpbHkgb24gSFRUUC4gSGVuY2UgdGhlIGRpc2N1c3Npb24gYWJvdXQgZGVlcCBsaW5rcyBhbmQg c28gb24uDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BbiBhbHRlcm5hdGl2ZSBtaWdodCBiZSBw cm92aWRlZCBieSB3YXNtL3dhc2kgKHJ1bm5pbmcgYSBsb2NhbCBzYW5kYm94IG9uIHlvdXIgcGhv bmUsIGZvciB5b3VyIG93biBBUyksIGJ1dCBpdCdzIHJlYWxseSBlYXJseSBzdGFnZS4gVGhpcyBh bHNvIHBvc2VzIGFub3RoZXIgcXVlc3Rpb24gdGhhdCBEZW5pcyBoYXMgcHV0IGZvcndhcmQsIGku ZS4gaG93IGRvIHdlIGhhbmRsZSB0aGUgbXVsdGlwbGUgQVMgc2NlbmFyaW8gKGxpa2VseSB0bw0K IG9jY3VyIHRoZW4pLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RmFiaWVu Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxkaXYgY2xhc3M9InhfZ21haWxfcXVvdGUiPg0K PGRpdiBkaXI9Imx0ciIgY2xhc3M9InhfZ21haWxfYXR0ciI+T24gV2VkLCBOb3YgMTgsIDIwMjAg YXQgMTI6MTYgUE0gRnJhbmNpcyBQb3VhdGNoYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZwb0BhZG9y c3lzLmRlIj5mcG9AYWRvcnN5cy5kZTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgY2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44 ZXg7IGJvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpOyBwYWRkaW5nLWxlZnQ6 MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBpZD0ieF9nbWFpbC1tXy03MTUyNDE4ODgyODc1 MDg2MzgyYXBwZW5kb25zZW5kIiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2 ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQpXZSBhcmUgZHJpZnRp bmcgYXdheSBmcm9tIHRoZSBvcmlnaW5hbCBwcm9ibGVtIHNwYWNlLjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1z aXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KPHVsPg0KPGxpPk15IG9yaWdpbmFsIG1lbnRp b24gd2FzIGFib3V0IHRoZSAmcXVvdDtQT1NUJnF1b3Q7IHJlcXVlc3QsIHRoYXQgc3Vic3VtZXMg dGhhdCB0aGUgJnF1b3Q7QVMmcXVvdDsgaXMgYSAmcXVvdDtTZXJ2ZXImcXVvdDsuIERlc2lnbmlu ZyBhIG5ldyBwcm90b2NvbCwgd2UgY2Fubm90IGFmZm9yZCB0aGlzIGxpbWl0YXRpb24uPC9saT48 bGk+SSBqdXN0IG1lbnRpb25lZCBTSU9QIHRvIHNob3cgYSBrbm93biBhbmQgY2xvc2VkIGV4YW1w bGU/IExldCB1cyBub3QgZm9jdXMgb24gdGhlIGRldmljZSBsb2NhbCBkaXNjb3Zlcnkgc2NoZW1l IChsaWtlIG9wZW5pZDopIGZvciBub3cuPC9saT48bGk+QXMgY2FwYWJpbGl0eSBvZiBob2xkaW5n IHByaXZhdGUga2V5cyBvbiB1c2VyIGRldmljZSBldm9sdmVzLCBzZXJ2ZXItYmFzZWQgaXNzdWlu ZyBvZiB0b2tlbiB3aWxsIGJlIGZhZGluZyBvdXQgZ2l2aW5nIHdheSB0byBkZXZpY2UgbG9jYWwg Z2VuZXJhdGlvbiBvZiB0b2tlbi48L2xpPjwvdWw+DQo8ZGl2PldoaWxlIGRlc2lnbmluZyBHTkFQ LCBsZXQgdXMgYXNzdW1lIHRoZSBBUy1Sb2xlIGNhbiBiZSBleGVyY2lzZWQgb24gYSB1c2VyIGRl dmljZSBhbmQgZGVzaWduIHRoZSBwcm90b2NvbCB0byBob25vciB0aGF0LjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj4vRnJhbmNpczwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGlj YSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQo8L2Rpdj4N CjxociBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRoOjk4JSI+DQo8ZGl2IGlkPSJ4 X2dtYWlsLW1fLTcxNTI0MTg4ODI4NzUwODYzODJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZv bnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgY29sb3I9IiMwMDAwMDAiIHN0eWxlPSJmb250 LXNpemU6MTFwdCI+PGI+RnJvbTo8L2I+IFRYQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0 aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoLWJvdW5jZXNAaWV0Zi5v cmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGljaw0KIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86 ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDE3LCAyMDIwIDE6 MjggUE08YnI+DQo8Yj5Ubzo8L2I+IFRvbSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21h c2NsaW5nYW5qb25lc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50aG9tYXNjbGluZ2Fuam9u ZXNAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEZhYmllbiBJbWJhdWx0ICZsdDs8 YSBocmVmPSJtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPC9hPiZndDs7IERlbmlzICZsdDs8YSBocmVmPSJtYWls dG86ZGVuaXMuaWV0ZkBmcmVlLmZyIiB0YXJnZXQ9Il9ibGFuayI+ZGVuaXMuaWV0ZkBmcmVlLmZy PC9hPiZndDs7IEdOQVAgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86dHhhdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoQGlldGYub3JnPC9hPiZndDs7DQogSnVzdGlu IFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxh bmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbR05B UF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtZ25hcC1jb3JlLXByb3RvY29sLTAwPC9mb250Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPkdvdCBpdC4mbmJz cDs8YnI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TbyB3ZWIgYXBwcyBpbnZva2UgYSBvcGVu aWQ6IGRlZXAgbGluayBhbmQgaG9wZSB0aGVyZSBpcyBhbiBhcHAgdG8gaGFuZGxlIHRoZSBvcGVu aWQ6IHNjaGVtZT8gLi4uIGFuZCB0aGF0IGl0IGlzIHRoZSB1c2VyJ3Mgd2FsbGV0IHJhdGhlciB0 aGFuIHNvbWUgbWFsd2FyZSB0aGF0IGhhcyByZWdpc3RlcmVkIG9wZW5pZDogb24gdGhlIG1vYmls ZSBkZXZpY2U/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BIG5hdGl2ZSBhcHAgY2Fu IGF0dGVtcHQgdG8gb3BlbiBhIGRlZXAgbGluayBhc3NvY2lhdGVkIHdpdGggYW4gYXBwLCBhbmQg d2lsbCBmYWlsIGlmIHRoZSBhcHAgaXMgbm90IHRoZXJlLiBJZiB0aGUgYXBwIGlzIHRoZXJlLCBp dCB3aWxsIGJlIG9wZW5lZCwgc28gdGhpcyBjYW4ndCBiZSB1c2VkIHRvIHNpbGVudGx5IHRlc3Qg aWYgYW4gYXBwIGlzIHByZXNlbnQsIGJ1dCBpdCBkb2VzIGFsbG93IGEgbmF0aXZlIGFwcCB0byBw cm92aWRlIGFuDQogYWx0ZXJuYXRpdmUgZXhwZXJpZW5jZSBpZiBhbiBhcHAgaXMgbm90IHByZXNl bnQuIEkgZG9uJ3QgdGhpbmsgdGhpcyB3b3JrcyB3aXRoIGN1c3RvbSBzY2hlbWVzIC4uLiBhbmQg SSBkb24ndCBrbm93IGhvdyBpdCBjb3VsZCB3b3JrIGZyb20gYSB3ZWIgYXBwIG9uIHRoZSBwaG9u ZSB3aXRoIHRoZSBjdXJyZW50IFNhZmFyaSBBUElzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+QXBwbGUgd2FybnMgYWdhaW5zdCB1c2luZyBjdXN0b20gc2NoZW1lcyBbMV0gLi4uIGJ1 dCBwZXJoYXBzIHRoZXkgY2FuIGJlIGNvbnZpbmNlZCB0byBtYWtlIG9wZW5pZDogYSBtYW5hZ2Vk IHNjaGVtZSBzaW1pbGFyIHRvIG1haWx0bzosIHRlbDosIHNtczosIGZhY2V0aW1lOiA/PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bMV0mbmJzcDs8YSBocmVmPSJodHRwczovL2RldmVs b3Blci5hcHBsZS5jb20vZG9jdW1lbnRhdGlvbi94Y29kZS9hbGxvd2luZ19hcHBzX2FuZF93ZWJz aXRlc190b19saW5rX3RvX3lvdXJfY29udGVudC9kZWZpbmluZ19hX2N1c3RvbV91cmxfc2NoZW1l X2Zvcl95b3VyX2FwcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxlLmNv bS9kb2N1bWVudGF0aW9uL3hjb2RlL2FsbG93aW5nX2FwcHNfYW5kX3dlYnNpdGVzX3RvX2xpbmtf dG9feW91cl9jb250ZW50L2RlZmluaW5nX2FfY3VzdG9tX3VybF9zY2hlbWVfZm9yX3lvdXJfYXBw PC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgaHNwYWNlPSJzdHJlYWstcHQtbWFyayIgc3R5bGU9Im1heC1oZWlnaHQ6MXB4Ij48aW1n IGFsdD0iIiBzdHlsZT0id2lkdGg6MHB4OyBtYXgtaGVpZ2h0OjBweDsgb3ZlcmZsb3c6aGlkZGVu IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9Z WEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTAxMTQ5 MGJlLWQzYTAtNGIyYy04YWJiLWU1MTE3NWUzYWUxOSI+PGZvbnQgY29sb3I9IiNmZmZmZmYiIHNp emU9IjEiPuGQpzwvZm9udD48L2Rpdj4NCjxicj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5PbiBU dWUsIE5vdiAxNywgMjAyMCBhdCAxMDowNiBBTSBUb20gSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0 bzp0aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGhvbWFzY2xp bmdhbmpvbmVzQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQ6MXB4IHNvbGlk IHJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8 ZGl2PllvdSBhcmUgLSB0aGF0IGlzIG5vdCBzdGFuZGFyZCB3aGljaCBpcyBvcGVpbmQ6Ly88L2Rp dj4NCjxkaXY+VGhpcyBpcyB0aGUgb25lIHN0ZXAgdGhhdCBzdGlsbCBuZWVkcyB0byBiZSBvcHRp bWl6ZWQgZm9yIFNJT1AgdG8gaGF2ZSBnb29kIFVYLjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5QZWFjZSAuLnRvbTwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxk aXY+DQo8ZGl2IGRpcj0ibHRyIj5PbiBUdWUsIE5vdiAxNywgMjAyMCBhdCA5OjU5IEFNIERpY2sg SGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdDox cHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0i bHRyIj5IaSBUb20NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkgd2F0Y2hlZCB5b3VyIHZpZGVv IChJIHdhdGNoZWQgYXQgMlggc3BlZWQpPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5M b29rcyBsaWtlIHRoZSBlbXBsb3ltZW50IHdlYnNpdGUgYXBwIHRoYXQgaXMgdXNpbmcgbG9jYWxo b3N0Ojg3NjUgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgd2FsbGV0LiBBbSBJIGNvcnJlY3Q/PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4vRGljayZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGhzcGFjZT0ic3RyZWFrLXB0LW1hcmsiIHN0eWxlPSJtYXgtaGVpZ2h0OjFweCI+PGltZyBh bHQ9IiIgc3R5bGU9IndpZHRoOjBweDsgbWF4LWhlaWdodDowcHg7IG92ZXJmbG93OmhpZGRlbiIg c3JjPSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhK a2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD0xMWE2MmNl Ni05YjRhLTRkNWYtODZjNS1kMmMxMTQzOTVhZWUiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjZmZm ZmZmIj7hkKc8L2ZvbnQ+PC9kaXY+DQo8YnI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+T24gVHVl LCBOb3YgMTcsIDIwMjAgYXQgOTo0NiBBTSBUb20gSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzp0 aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGhvbWFzY2xpbmdh bmpvbmVzQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJn YigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+V2VsbCwg aGVyZSdzIGEgZGVtby4gTm90ZSB0aGF0IGluIHRoaXMgY2FzZSB0aGUgQVMgaXMgbm90IG9ubGlu ZSBhbGwgb2YgdGhlIHRpbWUsIHNvIGl0IGlzIHJlYWxseSBpbXBsaWNpdCBmbG93IGFuZCB0aGUg T0lEQyBpZC10b2tlbiBjb21lcyBmcm9tIHRoZSBzaW9wIGRldmljZSBkaXJlY3RseS4NCjxkaXY+ KHdoZXRoZXIgdGhpcyBpcyBmcm9udC1jaGFubmVsIG9yIGJhY2sgY2hhbm5lbCBpcyBubyBsb25n ZXIgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24uKTxicj4NCjxkaXY+Tm93IGlmIGFuIGFsd2F5cy1v biBBUyBpcyByZXF1aXJlZCwgdGhhdCBpcyBwb3NzaWJsZSwgYnV0IHByb2JhYmx5IGJleW9uZCB0 aGUgc2NvcGUgb2YgdGhpcyBlZmZvcnQgYW5kIHdvdWxkIHJlcXVpcmUgc29tZXRoaW5nIGxpa2Ug YW4gYWdlbnQtaW4tdGhlLXNreSZuYnNwOyh3aXRoIGRpYW1vbmRzKS48L2Rpdj4NCjxkaXY+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij5oZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSA5IG1pbiB2 aWRlbyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu dXMvdjIvdXJsP3U9aHR0cHMtM0FfX3lvdXR1LmJlX1RxNGh3N1g1U1cwJmFtcDtkPUR3TUZhUSZh bXA7Yz0ycGxJM2hYSDh3dzNqMmc4cFYxOVFISWY0U21LX0ktRW9sX3A5UDBDdHRFJmFtcDtyPUQ1 bG5mb2EyTVZaV0VMcVZiYno3MW9vZWxiUDdyVkdDakdEU0JOdlVwWVEmYW1wO209aXhzdWRHU3Jf ZGhHLVNMaWF0YjRTejlGV3NsbXl3bll5WkFPTGdaeGhsOCZhbXA7cz1qZExMeTBHMUpUUUNBT0Ja NlBlVWdJMGtpQ3RWSlhycnUwVlRvWVdsTlo4JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxl PSJmb250LXNpemU6MTRweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij5odHRwczovLzxz cGFuPnlvdXR1PC9zcGFuPi48c3Bhbj5iZTwvc3Bhbj4vVHE0aHc3WDVTVzA8L3NwYW4+PC9hPjxi ciBjbGVhcj0iYWxsIj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0K PGRpdj5QZWFjZSAuLnRvbTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPk9uIFR1ZSwg Tm92IDE3LCAyMDIwIGF0IDk6MjAgQU0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBw eCAwLjhleDsgYm9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmct bGVmdDoxZXgiPg0KPGRpdj5VbHRpbWF0ZWx5LCBpbiBtb3N0IHNpdHVhdGlvbnMgbGlrZSB0aGVz ZSBpbiB0aGUgcmVhbCB3b3JsZCwgdGhlIGh1cmRsZSBpc27igJl0IHRlY2huaWNhbCBjb21wYXRp YmlsaXR5IHNvIG11Y2ggYXMgaXQgaXMgdHJ1c3QgY29tcGF0aWJpbGl0eS4gVGhlIFJQIChjbGll bnQpIG5lZWRzIHRvIGhhdmUgc29tZSBpbmNlbnRpdmUgdG8gdHJ1c3QgdGhlIGFzc2VydGlvbnMg YW5kIGlkZW50aXR5IGluZm9ybWF0aW9uIHRoYXTigJlzIGNvbWluZyBmcm9tDQogdGhlIEFTLiBU aGUgc2FtZSBpcyB0cnVlIGZvciBhbiBSUyB0cnVzdGluZyB0b2tlbnMgZnJvbSB0aGUgQVMuIFRo ZSBoYXJkIHF1ZXN0aW9uIGlzIGxlc3Mg4oCcaG934oCdIHRvIGRvIHRoYXQgKHdoaWNoIFNTSSBh bnN3ZXJzKSwgYnV0IG1vcmUg4oCcd2h54oCdIHRvIGRvIHRoYXQgKHdoaWNoIFNTSSBkb2VzbuKA mXQgYW5zd2VyIHZlcnkgd2VsbCwgYmVjYXVzZSBpdOKAmXMgYSBoYXJkIHF1ZXN0aW9uKS4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlN0aWxsOiBpdOKAmXMgZGVmaW5pdGVseSBhIHF1ZXN0aW9u IGFib3V0IGhvdyB0byBzdXBwb3J0IHRoaXMg4oCcQVMgb24gZGV2aWNl4oCdIGVsZW1lbnQuIFdl 4oCZdmUgZ290IHRoZSBzdGFydCBvZiBpdCBtb3JlIHRoYW4gT0F1dGgyL09JREMgaGF2ZSBieSBh bGxvd2luZyB0aGUgYm9vdHN0cmFwIG9mIHRoZSBwcm9jZXNzIGZyb20gYSBzdGFydGluZyBjYWxs OiB0aGUgaW50ZXJhY3Rpb24gYW5kIGNvbnRpbnVhdGlvbiBVUklzIGhhbmRlZCBiYWNrIGJ5DQog dGhlIEFTIGRvbuKAmXQgbmVlZCB0byBiZSB0aGUgc2FtZSBVUklzIHRoYXQgdGhlIGNsaWVudCBz dGFydHMgd2l0aCwgc28ganVzdCBsaWtlIFNJT1AgdGhlIHByb2Nlc3MgY2FuIHN0YXJ0IGluIEhU VFAgYW5kIHBvdGVudGlhbGx5IG1vdmUgdG8gb3RoZXIgY29tbXVuaWNhdGlvbiBjaGFubmVscy4g QSBtYWpvciBkaWZmZXJlbmNlIGlzIHRoYXQgd2UgYXJlbuKAmXQgZGVwZW5kZW50IG9uIHRoZSBh c3N1bXB0aW9uIHRoYXQgdGhlIHVzZXIgd2lsbCBhbHdheXMNCiBiZSBpbiBhIGJyb3dzZXIgYXQg c29tZSBzdGFnZSwgYW5kIHNvIHRoZSB3aG9sZSByYWZ0IG9mIGZyb250LWNoYW5uZWwgbWVzc2Fn ZXMgdGhhdCBTSU9QIHJlbGllcyBvbiBkb2VzbuKAmXQgZmx5LiBUaGF0IHNhaWQsIHdl4oCZdmUg Z290IGFuIG9wcG9ydHVuaXR5IHRvIG1vcmUgZXhwbGljaXRseSBvcGVuIHVwIGFsdGVybmF0aXZl IGNvbW11bmljYXRpb24gY2hhbm5lbHMgaGVyZSwgYW5kIHRoYXTigJlzIHNvbWV0aGluZyBJ4oCZ ZCBsaWtlIHRvIHNlZSBlbmdpbmVlcmVkLA0KIGV2ZW4gaWYgaXTigJlzIGFuIGV4dGVuc2lvbi4g SeKAmWQgbG92ZSB0byBzZWUgYSBjb25jcmV0ZSBwcm9wb3NhbCBhcyB0byBob3cgdGhhdCB3b3Vs ZCB3b3JrIG92ZXIgc3BlY2lmaWMgcHJvdG9jb2xzLCBzdGFydGluZyB3aXRoIHdoYXQgd2XigJl2 ZSBnb3QgdG9kYXkuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDvi gJQgSnVzdGluPGJyPg0KPGRpdj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+ T24gTm92IDE3LCAyMDIwLCBhdCAxMjowMyBQTSwgRmFiaWVuIEltYmF1bHQgJmx0OzxhIGhyZWY9 Im1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5mYWJpZW4u aW1iYXVsdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxicj4NCjxkaXY+DQo8ZGl2 IGRpcj0ibHRyIj5IaSBEZW5pcywgaGkgRnJhbmNpcywmbmJzcDsNCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkF0IHNvbWUgcG9pbnQgaW50ZWdyYXRpb24gd2l0aCBTU0kgKG9uIHRoZSBhdXRoZW50 aWNhdGlvbiBzaWRlKSB3aWxsIHByb2JhYmx5IG9jY3VyLCBpbmNsdWRpbmcgYW1vbmdzdCBvdGhl ciBwb3NzaWJpbGl0aWVzIFNJT1AgKHNpbmNlIHRoZXkgd29yayB3aXRoIE9wZW5JRCBhIHBhcnQg b2YgdGhlIHdvcmsgd2lsbCBwcm9iYWJseSBiZSBtYWRlIGVhc2llcikuJm5ic3A7PC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGF0IGJlaW5nIHNhaWQsIERlbmlzIGlzIHJpZ2h0LiBJ dCdzIG5vdCBhbiBBUy4gVGVjaG5pY2FsbHkgaXQncyBlbnRpcmVseSBwb3NzaWJsZSB0byByZWx5 IG9uIGEgZGVjZW50cmFsaXplZCB3YWxsZXQgKGZvciBpbnN0YW5jZSBvbiB5b3VyIHBob25lKSBh bmQgYSBjZW50cmFsaXplZCBBUy4gSSBrbm93IG9mIGEgZmV3IHN0dWRpZXMgb24gaG93IHRvIGRl Y2VudHJhbGl6ZSB0aGUgQVMgaXRzZWxmIChmb3IgaW5zdGFuY2UmbmJzcDs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZGpvbm8tb2F1dGgtZGVjZW50cmFsaXpl ZC0wMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o YXJkam9uby1vYXV0aC1kZWNlbnRyYWxpemVkLTAyPC9hPikuPC9kaXY+DQo8ZGl2Pk1heWJlIGl0 IGV4aXN0cywgYnV0IEknbSBzdGlsbCBsb29raW5nIGZvciByZWFsIHNjZW5hcmlvcyAob3IgZXZl biBhcmNoaXRlY3R1cmVzKSB3aGVyZSBhbiBBUyBpcyBkZXBsb3llZCBkaXJlY3RseSBvbiBhIHBo b25lLCBhbmQgdW5kZXIgdGhlIHNvbGUgYXV0aG9yaXR5IG9mIHRoZSBSTywgd2hpbGUgYmVpbmcg Y29tcGF0aWJsZSB3aXRoIHRoZSByZXN0IG9mIHRoZSB3b3JsZC4mbmJzcDs8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkNoZWVycyw8L2Rpdj4NCjxkaXY+RmFiaWVuPC9kaXY+DQo8L2Rp dj4NCjxicj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5PbiBUdWUsIE5vdiAxNywgMjAyMCBhdCA1 OjQ1IFBNIERlbmlzICZsdDs8YSBocmVmPSJtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyIiB0YXJn ZXQ9Il9ibGFuayI+ZGVuaXMuaWV0ZkBmcmVlLmZyPC9hPiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVm dDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pg0K PGRpdj5IZWxsbyZuYnNwOyBGcmFuY2lzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ U2VlIHR3byBjb21tZW50cyBpbiBsaW5lLjxicj4NCjwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXItY29sb3I6cmdiKDIwMCwyMDAsMjAwKTsgYm9yZGVyLWxlZnQt d2lkdGg6M3B4OyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgcGFkZGluZy1sZWZ0OjFleDsgbWFy Z2luLWxlZnQ6MC44ZXg7IGNvbG9yOnJnYigxMDIsMTAyLDEwMikiPg0KPGRpdiBkaXI9Imx0ciIg c3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjEy cHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KPGRp diBzdHlsZT0ibWFyZ2luOjBweCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4 OyB0ZXh0LWFsaWduOmxlZnQ7IGJhY2tncm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOjBweCI+QikgQ3VycmVudCBEb2N1bWVudDwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBweCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udD5Sb2xlcyBk ZXNjcmlwdGlvbiBzaGFsbCBub3QgaG9sZCBhbnkgYXNzdW1wdGlvbiBvbiB0aGUgcGh5c2ljYWwg c3RydWN0dXJlIG9mIHRoZSBwYXJ0eSBmdWxmaWxsaW5nIHRoZSByb2xlcy48L2ZvbnQ+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj5bRkldIG5vdCBzdXJlIHdoYXQg eW91IG1lYW48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNr Z3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPiZuYnNwO1tGUF0gZm9yIGV4YW1wbGUsIHdl IGFzc3VtZSB0aGUgQVMgaXMgYSBzZXJ2ZXIhIEluIG1vc3QgU1NJIGJhc2VkIHVzZSBjYXNlcywg dGhlIEFTIHdpbGwgYmUgcnVubmluZyBvbiB0aGUgdXNlciBkZXZpY2UuIFNlZSBTSU9QICg8YSBo cmVmPSJodHRwczovL2lkZW50aXR5LmZvdW5kYXRpb24vZGlkLXNpb3AvIiByZWw9Im5vb3BlbmVy IG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0ibWFyZ2luOjBweCI+aHR0cHM6Ly9p ZGVudGl0eS5mb3VuZGF0aW9uL2RpZC1zaW9wLzwvYT4pLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD5JIGJyb3dzZWQgdGhyb3VnaCB0aGUg dHdvIGRyYWZ0cywgaS5lLiA6PC9wPg0KPHVsPg0KPGxpPkRlY2VudHJhbGl6ZWQgSWRlbnRpZmll cnMgKERJRHMpIHYxLjAgQ29yZSBhcmNoaXRlY3R1cmUsIGRhdGEgbW9kZWwsIGFuZCByZXByZXNl bnRhdGlvbnMgVzNDIFdvcmtpbmcgRHJhZnQgMDggTm92ZW1iZXIgMjAyMA0KPC9saT48bGk+U2Vs Zi1Jc3N1ZWQgT3BlbklEIENvbm5lY3QgUHJvdmlkZXIgRElEIFByb2ZpbGUgdjAuMS4gRElGIFdv cmtpbmcgR3JvdXAgRHJhZnQ8L2xpPjwvdWw+DQo8cD5BdCBubyBwbGFjZSB3aXRoaW4gdGhlc2Ug dHdvIGRvY3VtZW50cywgaXQgaXMgcG9zc2libGUgdG8gaW1hZ2luZSB0aGF0ICZxdW90O3RoZSBB UyB3aWxsIGJlIHJ1bm5pbmcgb24gdGhlIHVzZXIgZGV2aWNlJnF1b3Q7Ljxicj4NCjwvcD4NCjxw PkZyb20gc2VjdGlvbiAzIG9mIHRoZSBESUYgV29ya2luZyBHcm91cCBEcmFmdDo8L3A+DQo8cD4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VW5saWtlIHRoZSBPSURDIEF1dGhv cml6YXRpb24gQ29kZSBGbG93IGFzIHBlciBbT0lEQy5Db3JlXSwgdGhlIFNJT1Agd2lsbCBub3Qg cmV0dXJuIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgUlAmcXVvdDsuPGJyPg0KPC9wPg0KPHA+QW4g SWRlbnRpdHkgV2FsbGV0IGlzIG5vdCBhbiBBUy4gPGJyPg0KPC9wPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUs MjU1LDI1NSkiPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjE1cHg7 IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+PGJyPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyLWNvbG9yOnJnYigyMDAsMjAwLDIwMCk7IGJvcmRlci1sZWZ0LXdp ZHRoOjNweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBhZGRpbmctbGVmdDoxZXg7IG1hcmdp bi1sZWZ0OjAuOGV4OyBjb2xvcjpyZ2IoMTAyLDEwMiwxMDIpIj4NCjxkaXYgZGlyPSJsdHIiIHN0 eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxMnB0 OyBmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjowcHg7IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0 ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPlJv bGVzOiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+LSZndDsgZ3JhbnQgZW5k cG9pbnQgb2YgdGhlIEFTOiBXaHkgaXMgdGhpcyBhIHBvc3QgcmVxdWVzdD8gVGhpcyBlbGltaW5h dGVzIHRoZSBjaGFuY2Ugb2YgaGF2aW5nIHVzZXIgZGV2aWNlIGhvc3RlZCBBUyAobm8gc2VydmVy KS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+W0ZJXSB3aGF0IHdvdWxkIHlvdSBwcm9wb3NlIGlu c3RlYWQ/PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9 InJlZCI+V291bGQgYWxzbyBiZSBpbnRlcmVzdGVkIHRvIHVuZGVyc3RhbmQgYmV0dGVyIHRoZSBk ZXBsb3ltZW50IG1vZGVsIHdoZW4gdGhlcmUgaXMgbm8gc2VydmVyLiBUaGF0J3Mgc29tZXRoaW5n IHRoYXQgd2FzIGRpc2N1c3NlZCBzZXZlcmFsIHRpbWVzIGJ1dCBJJ20gc3RpbGwgbWlzc2luZyB0 aGUgdW5kZXJseWluZyBhcmNoaXRlY3R1cmUgYW5kIHVzZSBjYXNlLjwvZm9udD48L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNr Z3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPiZuYnNwO1tGUF0gU2VlIGFib3ZlIChTSU9Q KS4gVGhlcmUgd2lsbCBiZSBhIGxvdCBvZiBpZGVudGl0eSB3YWxsZXRzIG9wZXJhdGVkIG9uIGVu ZCB1c2VyIGRldmljZS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPHA+U2VlIHRoZSBhYm92ZSBjb21tZW50LiBQbGVhc2UsIGRvIG5vdCBjb25m dXNlIGFuIElkZW50aXR5IFdhbGxldCB3aXRoIGFuIEF1dGhlbnRpY2F0aW9uIFNlcnZlciAoQVMp LjwvcD4NCjxwPkRlbmlzPGJyPg0KPC9wPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7 IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPjxicj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1jb2xvcjpyZ2IoMjAwLDIwMCwyMDAp OyBib3JkZXItbGVmdC13aWR0aDozcHg7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBwYWRkaW5n LWxlZnQ6MWV4OyBtYXJnaW4tbGVmdDowLjhleDsgY29sb3I6cmdiKDEwMiwxMDIsMTAyKSI+DQo8 ZGl2IGRpcj0ibHRyIiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4 OyBmb250LXNpemU6MTJwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fu cy1zZXJpZiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyB0ZXh0LWFsaWduOmxlZnQ7IGJhY2tn cm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46MHB4Ij4tJmd0OyBSZXNvdXJjZSBPd25lciAoUk8pIDogQXV0aG9yaXplcyB0aGUg cmVxdWVzdD8gRG9lcyBpdCBhdXRob3JpemUgdGhlIHJlcXVlc3Qgb3IgdGhlIGFjY2VzcyB0byBh IHJlc291cmNlPzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj5bRkldIHllcywgd2Ugc2hvdWxkIG1h a2UgdGhlIHdvcmRpbmcgY2xlYXJlcjwvZm9udD48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxl PSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxMnB0OyBm b250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjowcHg7IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+TWlzc2luZyBTZWN0aW9uIEludGVyYWN0 aW9uczo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPi0tJmd0OyBUaGlzIHNlY3Rpb24g c2hhbGwgaW50cm9kdWNlIHRoZSBub3Rpb24gb2YgaW50ZXJhY3Rpb24gYmVmb3JlIHdlIHN0YXJ0 IGxpc3RpbmcgaW50ZXJhY3Rpb24gdHlwZXMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJyZWQiPltGSV0g eWVzJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9Im1hcmdpbjowcHg7 IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPg0KPGRp diBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5OkNhbGlicmks QXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgdGV4 dC1hbGlnbjpsZWZ0OyBiYWNrZ3JvdW5kLWNvbG9yOndoaXRlIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJnaW46MHB4Ij4N CjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWlseTpDYWxp YnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7 IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPkludGVyYWN0aW9uIFR5cGVzOjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+LS0mZ3Q7IEkgcHJlZmVyIGEgY2xhc3NpZmlj YXRpb24gd2l0aCBSZWRpcmVjdCwgRGVjb3VwbGVkIGFuZCBFbWJlZGRlZCBpcy4gSW4gdGhlIGRy YWZ0LCB3ZSBoYXZlIG9uZSByZWRpcmVjdCBhbmQgMiBkZWNvdXBsZSBpbnRlcmFjdGlvbnMgYW5k IG5vdGhpbmcgZWxzZS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+W0ZJXSB0aGlzIHNob3VsZCBi ZSBoYW5kbGVkIGFzIGEgc3BlY2lmaWMgZGlzY3Vzc2lvbiBpdGVtLiBBcyBhIHJlbWluZGVyLCBo b3cgd291bGQgeW91IGRlZmluZSBlbWJlZGRlZD88L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJy ZWQiPkluIHByYWN0aWNlIHRoZXJlJ3MgYXQgbGVhc3QgdGhlc2UgbW9kZXM6PC9mb250PjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+LSByZWRpcmVjdCBh bmQgcmVkaXJlY3QgYmFjazwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxm b250IGNvbG9yPSJyZWQiPi0gcmVkaXJlY3QgdG8gZGlmZmVyZW50IGJyb3dzZXIgb3IgZGV2aWNl PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZvbnQgY29sb3I9InJlZCI+ LSB1c2VyIGNvZGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48Zm9udCBj b2xvcj0icmVkIj4tIENJQkE8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNTUsMjU1LDI1NSkiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+W0ZQXSBUaGlzIGNsYXNz aWZpY2F0aW9uIGlzIGxpbWl0ZWQuPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjow cHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPg0K PHVsPg0KPGxpPlJlZGlyZWN0OiBzYW1lIGRldmljZSwgc2FtZSBvciBkaWZmZXJlbnQgdXNlciBh Z2VudHMgKGJyb3dzZXIsIG1vYmlsZSBhcHAsIGRlc2t0b3AgYXBwLCAuLi4pPC9saT48bGk+RGVj b3VwbGVkOiBkaWZmZXJlbnQgZGV2aWNlczwvbGk+PGxpPkVtYmVkZGVkIDogUkMgY2FycmllcyBS TyBhdXRob3JpemF0aW9uIHRvIEFTPC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46MHB4OyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUp Ij48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYg c3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWlseTpDYWxpYnJpLEFy aWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IHRleHQt YWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWNvbG9yOnJnYigy MDAsMjAwLDIwMCk7IGJvcmRlci1sZWZ0LXdpZHRoOjNweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29s aWQ7IHBhZGRpbmctbGVmdDoxZXg7IG1hcmdpbi1sZWZ0OjAuOGV4OyBjb2xvcjpyZ2IoMTAyLDEw MiwxMDIpIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9 Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhl bHZldGljYSxzYW5zLXNlcmlmIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IHRleHQtYWxpZ246 bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4N CjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPlJlc291cmNlIEFjY2VzcyBSZXF1ZXN0IHZzLiBSZXNv dXJjZSBSZXF1ZXN0PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4tLSZndDsgQm90aCBh cmUgbWl4ZWQgdXAuIE5vIGNsYXJpZmljYXRpb24gb2YgdGhlIGNvbnRleHQgb2YgZWFjaCBzZWN0 aW9uLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MHB4Ij48Zm9udCBjb2xvcj0icmVkIj5bRkldIGNvdWxkIHlvdSBjbGFyaWZ5IHdoYXQg eW91J2QgZXhwZWN0LiZuYnNwOyBCdHcgb24gdGhpcyB0b3BpYywgdGhlcmUncyBhIG1vcmUgZ2Vu ZXJhbCBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgd2Ugc2hvdWxkIG1ha2UgYSBkaXN0aW5jdGlvbiBv ciBub3QuJm5ic3A7PC9mb250PjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweDsgZm9udC1zaXplOjE1cHg7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1 KSI+PGZvbnQgY29sb3I9InJlZCI+PHNwYW4gc3R5bGU9Im1hcmdpbjowcHg7IGNvbG9yOnJnYigw LDM2LDgxKSI+4oCLW0ZQXTogSGVyZTo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOjBweDsgZm9udC1zaXplOjE1cHg7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUs MjU1KSI+DQo8dWw+DQo8bGk+PGZvbnQgY29sb3I9InJlZCI+PHNwYW4gc3R5bGU9Im1hcmdpbjow cHg7IGNvbG9yOnJnYigwLDM2LDgxKSI+PHNwYW4gc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtZmFt aWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IHRleHQtYWxpZ246bGVmdDsg YmFja2dyb3VuZC1jb2xvcjp3aGl0ZSI+UmVzb3VyY2UgQWNjZXNzIFJlcXVlc3Q6IFJlcXVlc3Rp bmcgQWNjZXNzIHRvIGEgcmVzb3VyY2UuIFJlc3BvbnNlIGlzIGFuIGFjY2Vzcw0KIHRva2VuIChv ciBhbnkgdHlwZSBvZiBncmFudCk8L3NwYW4+PC9zcGFuPjwvZm9udD48L2xpPjxsaT48Zm9udCBj b2xvcj0icmVkIj48c3BhbiBzdHlsZT0ibWFyZ2luOjBweDsgY29sb3I6cmdiKDAsMzYsODEpIj48 c3BhbiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRp Y2Esc2Fucy1zZXJpZjsgdGV4dC1hbGlnbjpsZWZ0OyBiYWNrZ3JvdW5kLWNvbG9yOndoaXRlIj5S ZXNvdXJjZSBSZXF1ZXN0OiBSZXF1ZXN0IHRoZSByZXNvdXJjZS4gUmVzcG9uc2UgaXMgdGhlIHJl c291cmNlIChvciBhIGNvcnJlc3BvbmRpbmcNCiBleGVjdXRpb24pPC9zcGFuPjwvc3Bhbj48L2Zv bnQ+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0ibWFyZ2luOjBweCI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTJwdDsgZm9udC1mYW1pbHk6Q2Fs aWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4 OyB0ZXh0LWFsaWduOmxlZnQ7IGJhY2tncm91bmQtY29sb3I6d2hpdGUiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOjBweCI+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyLWNvbG9yOnJnYigyMDAsMjAwLDIwMCk7IGJvcmRlci1sZWZ0LXdp ZHRoOjNweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBhZGRpbmctbGVmdDoxZXg7IG1hcmdp bi1sZWZ0OjAuOGV4OyBjb2xvcjpyZ2IoMTAyLDEwMiwxMDIpIj4NCjxkaXYgZGlyPSJsdHIiIHN0 eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxMnB0 OyBmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjowcHg7IHRleHQtYWxpZ246bGVmdDsgYmFja2dyb3VuZC1jb2xvcjp3aGl0 ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPlRv a2VuIENvbnRlbnQgTmVnb3RpYXRpb248L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPi0t Jmd0OyBOb3QgZXhwcmVzc2VkIGFzIHN1Y2guIFRoaXMgaXMgY2VudHJhbCB0byBHTkFQIGFuZCBu b3QgcmVwcmVzZW50ZWQgZW5vdWdoJm5ic3A7IGluIHRoZSBkb2N1bWVudC48L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGZvbnQg Y29sb3I9InJlZCI+W0ZJXSByaWdodC4gVGhpcyBzaG91bGQgYmUgYSBzcGVjaWZpYyBkaXNjdXNz aW9uIGl0ZW0uJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9Im1hcmdp bjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjEycHQ7IGZvbnQtZmFt aWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBweDsgdGV4dC1hbGlnbjpsZWZ0OyBiYWNrZ3JvdW5kLWNvbG9yOndoaXRlIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij5SZXF1ZXN0aW5nICZxdW90O1VzZXImcXVvdDsgSW5m b3JtYXRpb248L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPndlIGlkZW50aWZ5IHR3byB0 eXBlcyBvZiB1c2VyczogUlEgYW5kIFJPLiBJdCB3aWxsIGJlIGJldHRlciBub3QgdG8gcmVmZXIg dG8gYSB1c2VyIGluIHRoaXMgZHJhZnQsIGJ1dCBlaXRoZXIgdG8gYSBSUSBvciBhbiBSTy48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBw eCI+PGZvbnQgY29sb3I9InJlZCI+W0ZJXSB5ZXMgdGhhdCB3b3VsZCBhdm9pZCBwb3RlbnRpYWwg bWlzdW5kZXJzdGFuZGluZ3MuIEFsdGhvdWdoIGluIHRoZSBlbmQsIHBlb3BsZSB3aWxsIHRyYW5z bGF0ZSBSUSBpbnRvIHVzZXImbmJzcDtvciBlbmQtdXNlciBtb3N0IG9mIHRoZSB0aW1lLiBDZiBp biBkZWZpbml0aW9uLCBjdXJyZW50bHkgd2UgaGF2ZSZuYnNwOzwvZm9udD48c3Bhbj48Zm9udCBj b2xvcj0icmVkIj5SZXF1ZXN0aW5nDQogUGFydHkgKFJRLCBha2EgJnF1b3Q7dXNlciZxdW90Oyk8 L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGJyPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9Im1hcmdpbjow cHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5 OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBweDsgdGV4dC1hbGlnbjpsZWZ0OyBiYWNrZ3JvdW5kLWNvbG9yOndoaXRlIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij5JbnRlcmFjdGlvbiBBZ2FpbjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij4tJmd0OyBGb3IgZWFjaCBp bnRlcmFjdGlvbiB0eXBlLCB3ZSB3aWxsIGhhdmUgdG8gZGVzY3JpYmUgdGhlIHByb3RvY29sIGZs b3cgYW5kIHRoZSBuYXR1cmUgYW5kIGJlaGF2aW9yIG9mIGludm9sdmVkIFJvbGVzIChQYXJ0aWVz KSwgRWxlbWVudHMsIFJlcXVlc3RzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPjxmb250IGNvbG9yPSJyZWQiPltG SV0geWVzJm5ic3A7Jm5ic3A7PC9mb250PjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBkaXI9 Imx0ciIgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1z aXplOjEycHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweDsgdGV4dC1hbGlnbjpsZWZ0OyBiYWNrZ3JvdW5kLWNv bG9yOndoaXRlIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBweCI+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjowcHg7IGZvbnQtc2l6ZToxNXB4OyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigy NTUsMjU1LDI1NSkiPltGUF0gV2lsbCB0aGVzZSBhbmQgaW50byB0aWNrZXRzPzwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjE1cHg7IGJhY2tncm91bmQtY29sb3I6cmdi KDI1NSwyNTUsMjU1KSI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250 LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj5CZXN0IHJlZ2Fy ZHMuPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4OyBmb250LXNpemU6MTVweDsgYmFja2dy b3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4vRnJhbmNpczwvZGl2Pg0KPGJyPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZmllbGRzZXQ+PC9maWVsZHNldD4gPC9i bG9ja3F1b3RlPg0KPHA+PGJyPg0KPC9wPg0KPC9kaXY+DQotLSA8YnI+DQpUWEF1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRYQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPlRYQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PGJyPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQotLSA8YnI+DQpUWEF1dGggbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOlRYQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRYQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHhhdXRoPC9hPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KLS0gPGJyPg0KVFhBdXRoIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpUWEF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UWEF1dGhA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90eGF1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxicj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KLS0gPGJyPg0KVFhBdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpUWEF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UWEF1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1 dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FR2P281MB0106245AD7828040C4BF0F7E8DE10FR2P281MB0106DEUP_-- From nobody Wed Nov 18 04:46:54 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 12B953A1868 for ; Wed, 18 Nov 2020 04:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTTPS_HTTP_MISMATCH=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=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 aTBI0z180EvO for ; Wed, 18 Nov 2020 04:46:48 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0: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 9F8FB3A1866 for ; Wed, 18 Nov 2020 04:46:48 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id t13so1884352ilp.2 for ; Wed, 18 Nov 2020 04:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iQglgJN22+P9VBsDfgjKo/CKlWmqlFOjUKLXsYUBdK4=; b=Ua4h1ZiJJe/MfebDUERBlnynO2wfmiJynOnrEEG6hf8Ck8+RkWyZV+uNTPZT6Xf2f7 de+AzesQf/jIuULUntWAkTT96shhFIgZprl6yUBJSk8i9DOJonUaVRipKeWtm9EohYjY 3WXLETnEaNTxiQGGEZoQErz1WHuRZavYorylj3b+8DaJ5WxlyI4U5V1A2grQwSfXZrGu bKsEk6fNq5P6TmJ9gM9+hLRXgtUKiDt4OXmltyvPKVK2x18bbQsys/sfd+wJ4VudxnGq nw6CsObTVhBCY7yMfLgdD09b40Yq0VI0MrZrl1hKYZqeWXA/RrjS7mk9zF/F1M5o7rp3 WqLA== 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=iQglgJN22+P9VBsDfgjKo/CKlWmqlFOjUKLXsYUBdK4=; b=cZkdMs+CIXjRfVVR02c4zA8Zp9DVJH/dIOsSJIb87VNsu/HUOvh320CAhluI+O613j D7WdyDNGnwb9N3jgtAovnu4PD23voWiy1rwa+ep0RSj7uiOgiQxuwosieYkPyWy9oOAi YxUvvrsrNFwrOjNij47NPTF073G8TnK5y/D/X8EAwp3x77JyaRjGcVw886PVh0zUdPpP ZiHOtlUtriSe6yRRdM/Xn5cKCb1xJcG+9cF/A3yNO3ZURaCjj+BQHHfovnAIuid/G2dn oMWcJwSZmEsjhkUwfaH4UUwGWWH32WQvOeU3WgOTupSBo6xKudvbW+Va2/DaocGbjZ8u jYNQ== X-Gm-Message-State: AOAM530w6QZSdSLtoIEBS+KLICid+r/tWWvSBqZkLsZy8N3SqIutqm0P WdOGjFhpj2u5ZI/DbjyLdTCbYjWQQy5OnxjxmXs= X-Google-Smtp-Source: ABdhPJzF7j/KBHtV+VG89pXOsdUP2I8EA4P6q9xTk0zLv9LinM1zKQX/SofzcvPERZZ3hEb0x///7fU3po91MnU10G0= X-Received: by 2002:a92:9a51:: with SMTP id t78mr181375ili.178.1605703607892; Wed, 18 Nov 2020 04:46:47 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 18 Nov 2020 13:46:36 +0100 Message-ID: To: Francis Pouatcha Cc: "txauth@ietf.org" , Dick Hardt , Tom Jones , Denis , Justin Richer Content-Type: multipart/alternative; boundary="00000000000029c0dd05b4610105" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 18 Nov 2020 12:46:52 -0000 --00000000000029c0dd05b4610105 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I find the proposal interesting. This is achievable for instance by leveraging TAPS https://tools.ietf.org/html/draft-ietf-taps-arch-09 Yet, if I remember correctly, the charter states that we rely on HTTP, so I'm not sure we're in the scope. On Wed, Nov 18, 2020 at 1:06 PM Francis Pouatcha wrote: > It would be nice if the protocol was designed at many layers of > abstraction. > > > - The first layer shall design abstract protocol flows, without > specification of the mode and mechanism of interaction. > - The second layer can instantiate the first layer for dedicated > interaction. Here we can talk http, we can define interactions that pr= esume > server based token generation, we can define interaction that run on u= ser > device based token generation. > > This is also the fundament of the structure I proposed for the spec ( > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). > > /Francis > > ------------------------------ > *From:* Fabien Imbault > *Sent:* Wednesday, November 18, 2020 6:35 AM > *To:* Francis Pouatcha > *Cc:* txauth@ietf.org ; Dick Hardt ; > Tom Jones ; Denis ; > Justin Richer > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Would make sense, but not so easy as we rely heavily on HTTP. Hence the > discussion about deep links and so on. > > An alternative might be provided by wasm/wasi (running a local sandbox on > your phone, for your own AS), but it's really early stage. This also pose= s > another question that Denis has put forward, i.e. how do we handle the > multiple AS scenario (likely to occur then). > > Fabien > > On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha wrote: > > We are drifting away from the original problem space. > > - My original mention was about the "POST" request, that subsumes that > the "AS" is a "Server". Designing a new protocol, we cannot afford thi= s > limitation. > - I just mentioned SIOP to show a known and closed example? Let us not > focus on the device local discovery scheme (like openid:) for now. > - As capability of holding private keys on user device evolves, > server-based issuing of token will be fading out giving way to device = local > generation of token. > > While designing GNAP, let us assume the AS-Role can be exercised on a use= r > device and design the protocol to honor that. > > Best regards, > /Francis > ------------------------------ > *From:* TXAuth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Sent:* Tuesday, November 17, 2020 1:28 PM > *To:* Tom Jones > *Cc:* Fabien Imbault ; Denis ; > GNAP Mailing List ; Justin Richer > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Got it. > > So web apps invoke a openid: deep link and hope there is an app to handle > the openid: scheme? ... and that it is the user's wallet rather than some > malware that has registered openid: on the mobile device? > > A native app can attempt to open a deep link associated with an app, and > will fail if the app is not there. If the app is there, it will be opened= , > so this can't be used to silently test if an app is present, but it does > allow a native app to provide an alternative experience if an app is not > present. I don't think this works with custom schemes ... and I don't kno= w > how it could work from a web app on the phone with the current Safari API= s. > > Apple warns against using custom schemes [1] ... but perhaps they can be > convinced to make openid: a managed scheme similar to mailto:, tel:, > sms:, facetime: ? > > [1] > https://developer.apple.com/documentation/xcode/allowing_apps_and_website= s_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app > > > =E1=90=A7 > > On Tue, Nov 17, 2020 at 10:06 AM Tom Jones > wrote: > > You are - that is not standard which is opeind:// > This is the one step that still needs to be optimized for SIOP to have > good UX. > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote: > > Hi Tom > > I watched your video (I watched at 2X speed) > > Looks like the employment website app that is using localhost:8765 to > communicate with the wallet. Am I correct? > > /Dick > =E1=90=A7 > > On Tue, Nov 17, 2020 at 9:46 AM Tom Jones > wrote: > > Well, here's a demo. Note that in this case the AS is not online all of > the time, so it is really implicit flow and the OIDC id-token comes from > the siop device directly. > (whether this is front-channel or back channel is no longer an interestin= g > question.) > Now if an always-on AS is required, that is possible, but probably beyond > the scope of this effort and would require something like an > agent-in-the-sky (with diamonds). > here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 > > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: > > Ultimately, in most situations like these in the real world, the hurdle > isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP > (client) needs to have some incentive to trust the assertions and identit= y > information that=E2=80=99s coming from the AS. The same is true for an RS= trusting > tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to do= that (which SSI > answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, > because it=E2=80=99s a hard question). > > Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on device=E2=80=9D > element. We=E2=80=99ve got the start of it more than OAuth2/OIDC have by = allowing > the bootstrap of the process from a starting call: the interaction and > continuation URIs handed back by the AS don=E2=80=99t need to be the same= URIs that > the client starts with, so just like SIOP the process can start in HTTP a= nd > potentially move to other communication channels. A major difference is > that we aren=E2=80=99t dependent on the assumption that the user will alw= ays be in > a browser at some stage, and so the whole raft of front-channel messages > that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an = opportunity to > more explicitly open up alternative communication channels here, and that= =E2=80=99s > something I=E2=80=99d like to see engineered, even if it=E2=80=99s an ext= ension. I=E2=80=99d love > to see a concrete proposal as to how that would work over specific > protocols, starting with what we=E2=80=99ve got today. > > =E2=80=94 Justin > > On Nov 17, 2020, at 12:03 PM, Fabien Imbault > wrote: > > Hi Denis, hi Francis, > > At some point integration with SSI (on the authentication side) will > probably occur, including amongst other possibilities SIOP (since they wo= rk > with OpenID a part of the work will probably be made easier). > > That being said, Denis is right. It's not an AS. Technically it's entirel= y > possible to rely on a decentralized wallet (for instance on your phone) a= nd > a centralized AS. I know of a few studies on how to decentralize the AS > itself (for instance > https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). > Maybe it exists, but I'm still looking for real scenarios (or even > architectures) where an AS is deployed directly on a phone, and under the > sole authority of the RO, while being compatible with the rest of the > world. > > Cheers, > Fabien > > On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: > > Hello Francis, > > See two comments in line. > > > B) Current Document > > Roles description shall not hold any assumption on the physical structure > of the party fulfilling the roles. > [FI] not sure what you mean > > [FP] for example, we assume the AS is a server! In most SSI based use > cases, the AS will be running on the user device. See SIOP ( > https://identity.foundation/did-siop/). > > I browsed through the two drafts, i.e. : > > - Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, > and representations W3C Working Draft 08 November 2020 > - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working > Group Draft > > At no place within these two documents, it is possible to imagine that > "the AS will be running on the user device". > > From section 3 of the DIF Working Group Draft: > > "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the > SIOP will not return an access token to the RP". > > An Identity Wallet is not an AS. > > > Roles: > -> grant endpoint of the AS: Why is this a post request? This eliminates > the chance of having user device hosted AS (no server). > [FI] what would you propose instead? > Would also be interested to understand better the deployment model when > there is no server. That's something that was discussed several times but > I'm still missing the underlying architecture and use case. > > [FP] See above (SIOP). There will be a lot of identity wallets operated > on end user device. > > See the above comment. Please, do not confuse an Identity Wallet with an > Authentication Server (AS). > > Denis > > > -> Resource Owner (RO) : Authorizes the request? Does it authorize the > request or the access to a resource? > [FI] yes, we should make the wording clearer > > Missing Section Interactions: > --> This section shall introduce the notion of interaction before we star= t > listing interaction types. > [FI] yes > > Interaction Types: > --> I prefer a classification with Redirect, Decoupled and Embedded is. I= n > the draft, we have one redirect and 2 decouple interactions and nothing > else. > [FI] this should be handled as a specific discussion item. As a reminder, > how would you define embedded? > > In practice there's at least these modes: > - redirect and redirect back > - redirect to different browser or device > - user code > - CIBA > > [FP] This classification is limited. > > - Redirect: same device, same or different user agents (browser, > mobile app, desktop app, ...) > - Decoupled: different devices > - Embedded : RC carries RO authorization to AS > > > > Resource Access Request vs. Resource Request > --> Both are mixed up. No clarification of the context of each section. > [FI] could you clarify what you'd expect. Btw on this topic, there's a > more general discussion on whether we should make a distinction or not. > > =E2=80=8B[FP]: Here: > > - Resource Access Request: Requesting Access to a resource. Response > is an access token (or any type of grant) > - Resource Request: Request the resource. Response is the resource (or > a corresponding execution) > > > Token Content Negotiation > --> Not expressed as such. This is central to GNAP and not represented > enough in the document. > [FI] right. This should be a specific discussion item. > > Requesting "User" Information > we identify two types of users: RQ and RO. It will be better not to refer > to a user in this draft, but either to a RQ or an RO. > [FI] yes that would avoid potential misunderstandings. Although in the > end, people will translate RQ into user or end-user most of the time. Cf = in > definition, currently we have Requesting Party (RQ, aka "user") > > > Interaction Again > -> For each interaction type, we will have to describe the protocol flow > and the nature and behavior of involved Roles (Parties), Elements, Reques= ts. > [FI] yes > > > [FP] Will these and into tickets? > > Best regards. > /Francis > > > > -- > 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 > > --00000000000029c0dd05b4610105 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I find the proposal interesting. This is achievable for in= stance by leveraging TAPS=C2=A0https://tools.ietf.org/html/draft-ietf-taps-arch-09=

Yet, if I remember correctly, the charter states that w= e rely on HTTP, so I'm not sure we're in the scope.=C2=A0

On W= ed, Nov 18, 2020 at 1:06 PM Francis Pouatcha <fpo@adorsys.de> wrote:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_4799609422633043705LPlnk338391" target=3D"_blank">https://githu= b.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From= : Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf= .org <txauth@ie= tf.org>; Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.c= om>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrot= e:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org> on behalf = of Dick Hardt <dick.h= ardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; GNAP = Mailing List <txaut= h@ietf.org>; Justin Richer <jri= cher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@g= mail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com>= wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gm= ail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be/Tq4= hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote= :
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> w= rote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.iet= f.org/html/draft-hardjono-oauth-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possible to imagine that &= quot;the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code = Flow as per [OIDC.Core], the SIOP will not return an access token to the RP= ".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity Wallet with an= Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



--
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
--00000000000029c0dd05b4610105-- From nobody Wed Nov 18 07:49: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 5FF0F3A0B77 for ; Wed, 18 Nov 2020 07:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=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 fI-vCGR5Sfdg for ; Wed, 18 Nov 2020 07:49: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 0DB5C3A03FC for ; Wed, 18 Nov 2020 07:49:45 -0800 (PST) Received: from [192.168.1.19] (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 0AIFnbFs019732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 10:49:37 -0500 From: Justin Richer Message-Id: <68D346BD-6138-4DB9-B8AB-F3406867D45F@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_F6106310-1987-4FD7-9E6C-70F4FBC632AC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 18 Nov 2020 10:49:36 -0500 In-Reply-To: Cc: Francis Pouatcha , "txauth@ietf.org" , Dick Hardt , Tom Jones , Denis To: Fabien Imbault References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 18 Nov 2020 15:49:49 -0000 --Apple-Mail=_F6106310-1987-4FD7-9E6C-70F4FBC632AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One of the core enhancements of GNAP over OAuth 2 is that the protocol = always starts same way, and we=E2=80=99re doing that by using an HTTP = POST request. In OAuth 2, the client could start off by doing a redirect = through the browser to the authorization endpoint, or calling the token = endpoint, or calling the device endpoint, or calling the PAR endpoint, = or calling the RS (in UMA), or =E2=80=A6 This is something that GNAP can make better, and in the current design = everything starts the same way by calling the same endpoint, and so = it=E2=80=99s always HTTP POST to start.=20 However, what I was trying to point out earlier in the thread is that = the steps :after: that initial request could move to other protocols and = communication methods, to allow for on-device AS functions once that = bootstrap starts things off. So that initial HTTP POST could be handled = by a surrogate service that will hand off the processing to another = system. That next step, as we=E2=80=99re defining it right now with the = =E2=80=9Ccontinue=E2=80=9D function, is still HTTP and JSON based. But = that=E2=80=99s not to say that an extension could define another = response field, separate from =E2=80=9Ccontinue=E2=80=9D, that uses a = different communication mechanism like DIDComm. I get the desire to have an abstraction built into the protocol. In my = experience with many different specs over the years, having deep = abstractions over one instantiation tend to not help, because the = abstraction inevitably bakes in a bunch of assumptions about the only = concrete abstraction and you don=E2=80=99t realize these assumptions are = there until you try to add another abstraction. Therefore, GNAP is = taking the approach of doing a strong binding to HTTP/JSON to start, and = if we can abstract the pieces and concepts and extend beyond that, then = we=E2=80=99ll do so when we=E2=80=99ve got items we can abstract over. =E2=80=94 Justin > On Nov 18, 2020, at 7:46 AM, Fabien Imbault = wrote: >=20 > I find the proposal interesting. This is achievable for instance by = leveraging TAPS https://tools.ietf.org/html/draft-ietf-taps-arch-09 = >=20 > Yet, if I remember correctly, the charter states that we rely on HTTP, = so I'm not sure we're in the scope.=20 >=20 > On Wed, Nov 18, 2020 at 1:06 PM Francis Pouatcha > wrote: > It would be nice if the protocol was designed at many layers of = abstraction. >=20 > The first layer shall design abstract protocol flows, without = specification of the mode and mechanism of interaction. > The second layer can instantiate the first layer for dedicated = interaction. Here we can talk http, we can define interactions that = presume server based token generation, we can define interaction that = run on user device based token generation. > This is also the fundament of the structure I proposed for the spec = (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30 = ). >=20 > /Francis >=20 > From: Fabien Imbault > > Sent: Wednesday, November 18, 2020 6:35 AM > To: Francis Pouatcha > > Cc: txauth@ietf.org >; Dick Hardt >; Tom Jones >; Denis >; Justin Richer > > Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > =20 > Would make sense, but not so easy as we rely heavily on HTTP. Hence = the discussion about deep links and so on. >=20 > An alternative might be provided by wasm/wasi (running a local sandbox = on your phone, for your own AS), but it's really early stage. This also = poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=20 >=20 > Fabien=20 >=20 > On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha > wrote: > We are drifting away from the original problem space. > My original mention was about the "POST" request, that subsumes that = the "AS" is a "Server". Designing a new protocol, we cannot afford this = limitation. > I just mentioned SIOP to show a known and closed example? Let us not = focus on the device local discovery scheme (like openid:) for now. > As capability of holding private keys on user device evolves, = server-based issuing of token will be fading out giving way to device = local generation of token. > While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that. >=20 > Best regards, > /Francis > From: TXAuth > on behalf of Dick Hardt = > > Sent: Tuesday, November 17, 2020 1:28 PM > To: Tom Jones > > Cc: Fabien Imbault >; Denis >; GNAP Mailing List >; Justin Richer > > Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > =20 > Got it.=20 >=20 > So web apps invoke a openid: deep link and hope there is an app to = handle the openid: scheme? ... and that it is the user's wallet rather = than some malware that has registered openid: on the mobile device? >=20 > A native app can attempt to open a deep link associated with an app, = and will fail if the app is not there. If the app is there, it will be = opened, so this can't be used to silently test if an app is present, but = it does allow a native app to provide an alternative experience if an = app is not present. I don't think this works with custom schemes ... and = I don't know how it could work from a web app on the phone with the = current Safari APIs. >=20 > Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, = sms:, facetime: ? >=20 > [1] = https://developer.apple.com/documentation/xcode/allowing_apps_and_websites= _to_link_to_your_content/defining_a_custom_url_scheme_for_your_app = >=20 >=20 > =E1=90=A7 >=20 > On Tue, Nov 17, 2020 at 10:06 AM Tom Jones = > = wrote: > You are - that is not standard which is opeind:// > This is the one step that still needs to be optimized for SIOP to have = good UX. > Peace ..tom >=20 >=20 > On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt > wrote: > Hi Tom >=20 > I watched your video (I watched at 2X speed) >=20 > Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct? >=20 > /Dick=20 > =E1=90=A7 >=20 > On Tue, Nov 17, 2020 at 9:46 AM Tom Jones = > = wrote: > Well, here's a demo. Note that in this case the AS is not online all = of the time, so it is really implicit flow and the OIDC id-token comes = from the siop device directly. > (whether this is front-channel or back channel is no longer an = interesting question.) > Now if an always-on AS is required, that is possible, but probably = beyond the scope of this effort and would require something like an = agent-in-the-sky (with diamonds). > here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 = > Peace ..tom >=20 >=20 > On Tue, Nov 17, 2020 at 9:20 AM Justin Richer > wrote: > Ultimately, in most situations like these in the real world, the = hurdle isn=E2=80=99t technical compatibility so much as it is trust = compatibility. The RP (client) needs to have some incentive to trust the = assertions and identity information that=E2=80=99s coming from the AS. = The same is true for an RS trusting tokens from the AS. The hard = question is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), = but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t = answer very well, because it=E2=80=99s a hard question). >=20 > Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of = it more than OAuth2/OIDC have by allowing the bootstrap of the process = from a starting call: the interaction and continuation URIs handed back = by the AS don=E2=80=99t need to be the same URIs that the client starts = with, so just like SIOP the process can start in HTTP and potentially = move to other communication channels. A major difference is that we = aren=E2=80=99t dependent on the assumption that the user will always be = in a browser at some stage, and so the whole raft of front-channel = messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve= got an opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a = concrete proposal as to how that would work over specific protocols, = starting with what we=E2=80=99ve got today.=20 >=20 > =E2=80=94 Justin >=20 >> On Nov 17, 2020, at 12:03 PM, Fabien Imbault = > wrote: >>=20 >> Hi Denis, hi Francis,=20 >>=20 >> At some point integration with SSI (on the authentication side) will = probably occur, including amongst other possibilities SIOP (since they = work with OpenID a part of the work will probably be made easier).=20 >>=20 >> That being said, Denis is right. It's not an AS. Technically it's = entirely possible to rely on a decentralized wallet (for instance on = your phone) and a centralized AS. I know of a few studies on how to = decentralize the AS itself (for instance = https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02 = ). >> Maybe it exists, but I'm still looking for real scenarios (or even = architectures) where an AS is deployed directly on a phone, and under = the sole authority of the RO, while being compatible with the rest of = the world.=20 >>=20 >> Cheers, >> Fabien >>=20 >> On Tue, Nov 17, 2020 at 5:45 PM Denis > wrote: >> Hello Francis, >>=20 >> See two comments in line. >>=20 >>>=20 >>> B) Current Document >>>=20 >>> Roles description shall not hold any assumption on the physical = structure of the party fulfilling the roles. >>> [FI] not sure what you mean >>> [FP] for example, we assume the AS is a server! In most SSI based = use cases, the AS will be running on the user device. See SIOP = (https://identity.foundation/did-siop/ = ). >> I browsed through the two drafts, i.e. : >>=20 >> Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, = and representations W3C Working Draft 08 November 2020 >> Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft >> At no place within these two documents, it is possible to imagine = that "the AS will be running on the user device". >>=20 >> =46rom section 3 of the DIF Working Group Draft: >>=20 >> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], = the SIOP will not return an access token to the RP". >>=20 >> An Identity Wallet is not an AS.=20 >>=20 >>>=20 >>> Roles:=20 >>> -> grant endpoint of the AS: Why is this a post request? This = eliminates the chance of having user device hosted AS (no server). >>> [FI] what would you propose instead? >>> Would also be interested to understand better the deployment model = when there is no server. That's something that was discussed several = times but I'm still missing the underlying architecture and use case. >>> [FP] See above (SIOP). There will be a lot of identity wallets = operated on end user device. >> See the above comment. Please, do not confuse an Identity Wallet with = an Authentication Server (AS). >>=20 >> Denis >>=20 >>>=20 >>> -> Resource Owner (RO) : Authorizes the request? Does it authorize = the request or the access to a resource? >>> [FI] yes, we should make the wording clearer >>>=20 >>> Missing Section Interactions: >>> --> This section shall introduce the notion of interaction before we = start listing interaction types. >>> [FI] yes=20 >>>=20 >>> Interaction Types: >>> --> I prefer a classification with Redirect, Decoupled and Embedded = is. In the draft, we have one redirect and 2 decouple interactions and = nothing else. >>> [FI] this should be handled as a specific discussion item. As a = reminder, how would you define embedded? >>>=20 >>> In practice there's at least these modes: >>> - redirect and redirect back >>> - redirect to different browser or device >>> - user code >>> - CIBA >>> [FP] This classification is limited. >>> Redirect: same device, same or different user agents (browser, = mobile app, desktop app, ...) >>> Decoupled: different devices >>> Embedded : RC carries RO authorization to AS >>>=20 >>>=20 >>> Resource Access Request vs. Resource Request >>> --> Both are mixed up. No clarification of the context of each = section. >>> [FI] could you clarify what you'd expect. Btw on this topic, = there's a more general discussion on whether we should make a = distinction or not.=20 >>> =E2=80=8B[FP]: Here: >>> Resource Access Request: Requesting Access to a resource. Response = is an access token (or any type of grant) >>> Resource Request: Request the resource. Response is the resource (or = a corresponding execution) >>>=20 >>> Token Content Negotiation >>> --> Not expressed as such. This is central to GNAP and not = represented enough in the document. >>> [FI] right. This should be a specific discussion item.=20 >>>=20 >>> Requesting "User" Information >>> we identify two types of users: RQ and RO. It will be better not to = refer to a user in this draft, but either to a RQ or an RO. >>> [FI] yes that would avoid potential misunderstandings. Although in = the end, people will translate RQ into user or end-user most of the = time. Cf in definition, currently we have Requesting Party (RQ, aka = "user") >>>=20 >>>=20 >>> Interaction Again >>> -> For each interaction type, we will have to describe the protocol = flow and the nature and behavior of involved Roles (Parties), Elements, = Requests. >>> [FI] yes =20 >>>=20 >>> [FP] Will these and into tickets? >>>=20 >>> Best regards. >>> /Francis >>>=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 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_F6106310-1987-4FD7-9E6C-70F4FBC632AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 One = of the core enhancements of GNAP over OAuth 2 is that the protocol = always starts same way, and we=E2=80=99re doing that by using an HTTP = POST request. In OAuth 2, the client could start off by doing a redirect = through the browser to the authorization endpoint, or calling the token = endpoint, or calling the device endpoint, or calling the PAR endpoint, = or calling the RS (in UMA), or =E2=80=A6

This is something that GNAP can make = better, and in the current design everything starts the same way by = calling the same endpoint, and so it=E2=80=99s always HTTP POST to = start. 

However, what I was trying to point out = earlier in the thread is that the steps :after: that initial request = could move to other protocols and communication methods, to allow for = on-device AS functions once that bootstrap starts things off. So that = initial HTTP POST could be handled by a surrogate service that will hand = off the processing to another system. That next step, as we=E2=80=99re = defining it right now with the =E2=80=9Ccontinue=E2=80=9D function, is = still HTTP and JSON based. But that=E2=80=99s not to say that an = extension could define another response field, separate from = =E2=80=9Ccontinue=E2=80=9D, that uses a different communication = mechanism like DIDComm.

I get the desire to have an abstraction built into the = protocol. In my experience with many different specs over the years, = having deep abstractions over one instantiation tend to not help, = because the abstraction inevitably bakes in a bunch of assumptions about = the only concrete abstraction and you don=E2=80=99t realize these = assumptions are there until you try to add another abstraction. = Therefore, GNAP is taking the approach of doing a strong binding to = HTTP/JSON to start, and if we can abstract the pieces and concepts and = extend beyond that, then we=E2=80=99ll do so when we=E2=80=99ve got = items we can abstract over.

 =E2=80=94 Justin

On Nov = 18, 2020, at 7:46 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

I find the proposal interesting. = This is achievable for instance by leveraging TAPS https://tools.ietf.org/html/draft-ietf-taps-arch-09

Yet, if I remember = correctly, the charter states that we rely on HTTP, so I'm not sure = we're in the scope. 

On Wed, Nov = 18, 2020 at 1:06 PM Francis Pouatcha <fpo@adorsys.de> wrote:
It would be nice if the protocol was designed at many layers of = abstraction.

  • The first layer shall design abstract protocol flows, = without specification of the mode and mechanism of interaction.
  • The second layer can instantiate the first layer for = dedicated interaction. Here we can talk http, we can define interactions = that presume server based token generation, we can define interaction = that run on user device based token generation.
This is also the fundament of the structure I proposed = for the spec (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Would make sense, but not so easy as we rely = heavily on HTTP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a = local sandbox on your phone, for your own AS), but it's really early = stage. This also poses another question that Denis has put forward, i.e. = how do we handle the multiple AS scenario (likely to occur then). 

Fabien 

On Wed, Nov 18, 2020 at 12:16 PM Francis = Pouatcha <fpo@adorsys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that = subsumes that the "AS" is a "Server". Designing a new protocol, we = cannot afford this limitation.
  • I just mentioned SIOP = to show a known and closed example? Let us not focus on the device local = discovery scheme (like openid:) for now.
  • As = capability of holding private keys on user device evolves, server-based = issuing of token will be fading out giving way to device local = generation of token.
While designing GNAP, let us assume the AS-Role can be = exercised on a user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth = <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; GNAP Mailing List <txauth@ietf.org>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of = draft-ietf-gnap-core-protocol-00
 
Got it. 

So web apps invoke a openid: deep link and hope there is = an app to handle the openid: scheme? ... and that it is the user's = wallet rather than some malware that has registered openid: on the = mobile device?

A native app can attempt to open a deep link associated = with an app, and will fail if the app is not there. If the app is there, = it will be opened, so this can't be used to silently test if an app is = present, but it does allow a native app to provide an alternative experience if an app is not present. I don't think this = works with custom schemes ... and I don't know how it could work from a = web app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but = perhaps they can be convinced to make openid: a managed scheme similar = to mailto:, tel:, sms:, facetime: ?

[1] https://developer.apple.com/documentation/xcode/allowing_apps_a= nd_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_= app


3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones = <thomasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized = for SIOP to have good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt = <dick.hardt@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using = localhost:8765 to communicate with the wallet. Am I correct?

/Dick 
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones = <thomasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case = the AS is not online all of the time, so it is really implicit flow and = the OIDC id-token comes from the siop device directly.
(whether this is front-channel or back channel is no = longer an interesting question.)
Now if an always-on AS is required, that is possible, = but probably beyond the scope of this effort and would require something = like an agent-in-the-sky (with diamonds).
here is the = link to the 9 min video   https://youtu.be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin = Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real = world, the hurdle isn=E2=80=99t technical compatibility so much as it is = trust compatibility. The RP (client) needs to have some incentive to = trust the assertions and identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The = hard question is less =E2=80=9Chow=E2=80=9D to do that (which SSI = answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80= =99t answer very well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to = support this =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got = the start of it more than OAuth2/OIDC have by allowing the bootstrap of = the process from a starting call: the interaction and continuation URIs = handed back by the AS don=E2=80=99t need to be the same URIs that the client starts = with, so just like SIOP the process can start in HTTP and potentially = move to other communication channels. A major difference is that we = aren=E2=80=99t dependent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel = messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve= got an opportunity to more explicitly open up alternative communication = channels here, and that=E2=80=99s something I=E2=80=99d like to see = engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete = proposal as to how that would work over specific protocols, starting = with what we=E2=80=99ve got today. 

 =E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Denis, hi Francis, 

At some point integration with SSI (on the = authentication side) will probably occur, including amongst other = possibilities SIOP (since they work with OpenID a part of the work will = probably be made easier). 

That being said, Denis is right. It's not an AS. = Technically it's entirely possible to rely on a decentralized wallet = (for instance on your phone) and a centralized AS. I know of a few = studies on how to decentralize the AS itself (for instance https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-= 02).
Maybe it exists, but I'm still looking for real = scenarios (or even architectures) where an AS is deployed directly on a = phone, and under the sole authority of the RO, while being compatible = with the rest of the world. 

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
Hello  Francis,

See two comments in line.


B) Current Document

Roles description = shall not hold any assumption on the physical structure of the party = fulfilling the roles.
[FI] = not sure what you mean
 [FP] for example, we assume the AS is a server! In = most SSI based use cases, the AS will be running on the user device. See = SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, = data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile = v0.1. DIF Working Group Draft

At no place within = these two documents, it is possible to imagine that "the AS will be = running on the user device".

=46rom section 3 of the DIF Working Group Draft:

      "Unlike the OIDC Authorization = Code Flow as per [OIDC.Core], the SIOP will not return an access token = to the RP".

An Identity Wallet is not an AS.


Roles: 
-> grant endpoint of the AS: Why = is this a post request? This eliminates the chance of having user device = hosted AS (no server).
[FI] = what would you propose instead?
Would = also be interested to understand better the deployment model when there = is no server. That's something that was discussed several times but I'm = still missing the underlying architecture and use case.
 [FP] See above (SIOP). There will be a lot of identity = wallets operated on end user device.

See the above comment. Please, do not confuse = an Identity Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : = Authorizes the request? Does it authorize the request or the access to a = resource?
[FI] = yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce = the notion of interaction before we start listing interaction = types.
[FI] = yes 

Interaction Types:
--> I prefer a classification = with Redirect, Decoupled and Embedded is. In the draft, we have one = redirect and 2 decouple interactions and nothing else.
[FI] = this should be handled as a specific discussion item. As a reminder, how = would you define embedded?

In = practice there's at least these modes:
- = redirect and redirect back
- = redirect to different browser or device
- = user code
- = CIBA
[FP] This classification is = limited.
  • Redirect: same device, same or different user agents = (browser, mobile app, desktop app, ...)
  • Decoupled: = different devices
  • Embedded : RC carries RO = authorization to AS


Resource Access Request vs. = Resource Request
--> Both are mixed up. No = clarification of the context of each section.
[FI] = could you clarify what you'd expect.  Btw on this topic, there's a = more general discussion on whether we should make a distinction or = not. 
=E2=80=8B[FP]: = Here:
  • Resource Access Request: = Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request = the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This = is central to GNAP and not represented enough  in the = document.
[FI] = right. This should be a specific discussion item. 

Requesting "User" Information
we identify two types of users: RQ = and RO. It will be better not to refer to a user in this draft, but = either to a RQ or an RO.
[FI] = yes that would avoid potential misunderstandings. Although in the end, = people will translate RQ into user or end-user most of the time. Cf = in definition, currently we have Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we = will have to describe the protocol flow and the nature and behavior of = involved Roles (Parties), Elements, Requests.
[FI] = yes  

[FP] Will these and into tickets?

Best regards.
/Francis



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

= --Apple-Mail=_F6106310-1987-4FD7-9E6C-70F4FBC632AC-- From nobody Wed Nov 18 08:18: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 97BCD3A0C28 for ; Wed, 18 Nov 2020 08:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTTPS_HTTP_MISMATCH=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=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 tYW2FYwCveEd for ; Wed, 18 Nov 2020 08:18:05 -0800 (PST) Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 5467B3A0C16 for ; Wed, 18 Nov 2020 08:18:05 -0800 (PST) Received: by mail-il1-x144.google.com with SMTP id l13so2497767ilg.3 for ; Wed, 18 Nov 2020 08:18:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hlt0FEiBSLfCI0mrC1jn0nK1wLvg1QgkZEmkK6lT8R0=; b=cA4wXH9lrhzWfGp6fldNztkQKJg6fLqEfjmi1uZX5bij2Z8tnsLKGTD00ZcWz7EE4h cqG76yDTrpxg2MDpXKbZdDn6Ucy3IwfgfocbVuUJnoR3yU/WiOM9gRHW83etZBdIyolY pl8mDnWGNkomDCsFPGu3aNAf9NO2oo/NfIjE3OpGfQtjppy+Lqnzi+dufc3Iqdt3dd7R Tf7RKb4XlVXlO+aTStC1y8EcbKUnyF4GruvUVAPr16QhvzaWPEIRVFeqDyGNeueqf+H4 0FJqZ8sIKkUU/67ZpaBA5WTsUQ0VEGaMSeuzxY//5+wyNL2cwCsyrkxoeV7ZY7ZQiEnw E6cg== 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=hlt0FEiBSLfCI0mrC1jn0nK1wLvg1QgkZEmkK6lT8R0=; b=BFUEj1WuyjImI6XT2uRDl8kKTanRjU/3Ml9HzWKIb44en/Qufw60leB42Gp8iAyzCN sieUVhNPQgaLUzPWFgfa9wqe2JqgYyppsa7ZXN9Bqj2rRT/Q6KI3hlB6Xt8gX/WPFYPs hQQs3DmiPHAXcT7+XdAKVNgnPsa2BBVNt1f2tFFRBc1p6CbqsPvPH/6xem994NlswXSk O1PCBR2znMN2H5HF9zB2Z7NTDPBhyuz7e/BLFVVbwNPfT0Rxvl6SB4q6mGz5Y1llhOHc M0BS0NW8kVhj8msRCHOGCFdQ1E+63j7pQrOV7KH4E2j0b08Chh/0x0J6yzPnx6iGMqW4 LR+w== X-Gm-Message-State: AOAM531JViq/OSmCarK+Nup58I0N2ed++0p8rD+XkJIlcrZAlk1Wnb1d GMr7ZGthgCb2xjUdhHCO8CotUxdaU0DEzztVvWo= X-Google-Smtp-Source: ABdhPJzi1h59HKeIx3BVLeWFRgPVl2Om3NYqMnQ40IYARM3KLMNq6gZzcl0Fc7B/6jxx6pcsFMJfvmNZL7+7S/3Irm0= X-Received: by 2002:a92:9a51:: with SMTP id t78mr1040348ili.178.1605716284564; Wed, 18 Nov 2020 08:18:04 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <68D346BD-6138-4DB9-B8AB-F3406867D45F@mit.edu> In-Reply-To: <68D346BD-6138-4DB9-B8AB-F3406867D45F@mit.edu> From: Fabien Imbault Date: Wed, 18 Nov 2020 17:17:53 +0100 Message-ID: To: Justin Richer Cc: Francis Pouatcha , "txauth@ietf.org" , Dick Hardt , Tom Jones , Denis Content-Type: multipart/alternative; boundary="000000000000c06fcc05b463f4d0" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 18 Nov 2020 16:18:09 -0000 --000000000000c06fcc05b463f4d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, As described by Justin in a previous comment, GNAP already gets us closer to the ultimate goal of security and privacy. But I'd agree we need to be very pragmatic. The issue here, in all cases, is that we're on unchartered territory. And even if we had a solution, it's unlikely most people would be able to implement it, as the underlying frameworks (TAPS, DIDComm, etc.) are really early stage. We already have concerns on how to implement some features in all mainstream languages, this would really make it a lot more complicated. I would suggest we first focus on designing GNAP around the lines we know should work well (while still having the idea of future extensions in mind, of course). There's already a lot to be done. So for now, I would keep the hypothesis that the AS is/are server(s) - just not limiting to a single AS is not that easy, so we could take it as a first step. Last I think we need to keep in mind that GNAP is probably not suitable for end-users directly, one would most probably expect that third-party services still provide the infrastructure. And since the business model around that exists, it also makes the dissemination of GNAP realistic. Fabien On Wed, Nov 18, 2020 at 4:49 PM Justin Richer wrote: > One of the core enhancements of GNAP over OAuth 2 is that the protocol > always starts same way, and we=E2=80=99re doing that by using an HTTP POS= T request. > In OAuth 2, the client could start off by doing a redirect through the > browser to the authorization endpoint, or calling the token endpoint, or > calling the device endpoint, or calling the PAR endpoint, or calling the = RS > (in UMA), or =E2=80=A6 > > This is something that GNAP can make better, and in the current design > everything starts the same way by calling the same endpoint, and so it=E2= =80=99s > always HTTP POST to start. > > However, what I was trying to point out earlier in the thread is that the > steps :after: that initial request could move to other protocols and > communication methods, to allow for on-device AS functions once that > bootstrap starts things off. So that initial HTTP POST could be handled b= y > a surrogate service that will hand off the processing to another system. > That next step, as we=E2=80=99re defining it right now with the =E2=80=9C= continue=E2=80=9D > function, is still HTTP and JSON based. But that=E2=80=99s not to say tha= t an > extension could define another response field, separate from =E2=80=9Ccon= tinue=E2=80=9D, > that uses a different communication mechanism like DIDComm. > > I get the desire to have an abstraction built into the protocol. In my > experience with many different specs over the years, having deep > abstractions over one instantiation tend to not help, because the > abstraction inevitably bakes in a bunch of assumptions about the only > concrete abstraction and you don=E2=80=99t realize these assumptions are = there > until you try to add another abstraction. Therefore, GNAP is taking the > approach of doing a strong binding to HTTP/JSON to start, and if we can > abstract the pieces and concepts and extend beyond that, then we=E2=80=99= ll do so > when we=E2=80=99ve got items we can abstract over. > > =E2=80=94 Justin > > On Nov 18, 2020, at 7:46 AM, Fabien Imbault > wrote: > > I find the proposal interesting. This is achievable for instance by > leveraging TAPS https://tools.ietf.org/html/draft-ietf-taps-arch-09 > > Yet, if I remember correctly, the charter states that we rely on HTTP, so > I'm not sure we're in the scope. > > On Wed, Nov 18, 2020 at 1:06 PM Francis Pouatcha wrote: > >> It would be nice if the protocol was designed at many layers of >> abstraction. >> >> >> - The first layer shall design abstract protocol flows, without >> specification of the mode and mechanism of interaction. >> - The second layer can instantiate the first layer for dedicated >> interaction. Here we can talk http, we can define interactions that p= resume >> server based token generation, we can define interaction that run on = user >> device based token generation. >> >> This is also the fundament of the structure I proposed for the spec ( >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). >> >> /Francis >> >> ------------------------------ >> *From:* Fabien Imbault >> *Sent:* Wednesday, November 18, 2020 6:35 AM >> *To:* Francis Pouatcha >> *Cc:* txauth@ietf.org ; Dick Hardt ; >> Tom Jones ; Denis ; >> Justin Richer >> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >> >> Would make sense, but not so easy as we rely heavily on HTTP. Hence the >> discussion about deep links and so on. >> >> An alternative might be provided by wasm/wasi (running a local sandbox o= n >> your phone, for your own AS), but it's really early stage. This also pos= es >> another question that Denis has put forward, i.e. how do we handle the >> multiple AS scenario (likely to occur then). >> >> Fabien >> >> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha wrote= : >> >> We are drifting away from the original problem space. >> >> - My original mention was about the "POST" request, that subsumes >> that the "AS" is a "Server". Designing a new protocol, we cannot affo= rd >> this limitation. >> - I just mentioned SIOP to show a known and closed example? Let us >> not focus on the device local discovery scheme (like openid:) for now= . >> - As capability of holding private keys on user device evolves, >> server-based issuing of token will be fading out giving way to device= local >> generation of token. >> >> While designing GNAP, let us assume the AS-Role can be exercised on a >> user device and design the protocol to honor that. >> >> Best regards, >> /Francis >> ------------------------------ >> *From:* TXAuth on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> *Sent:* Tuesday, November 17, 2020 1:28 PM >> *To:* Tom Jones >> *Cc:* Fabien Imbault ; Denis < >> denis.ietf@free.fr>; GNAP Mailing List ; Justin Richer = < >> jricher@mit.edu> >> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 >> >> Got it. >> >> So web apps invoke a openid: deep link and hope there is an app to handl= e >> the openid: scheme? ... and that it is the user's wallet rather than som= e >> malware that has registered openid: on the mobile device? >> >> A native app can attempt to open a deep link associated with an app, and >> will fail if the app is not there. If the app is there, it will be opene= d, >> so this can't be used to silently test if an app is present, but it does >> allow a native app to provide an alternative experience if an app is not >> present. I don't think this works with custom schemes ... and I don't kn= ow >> how it could work from a web app on the phone with the current Safari AP= Is. >> >> Apple warns against using custom schemes [1] ... but perhaps they can be >> convinced to make openid: a managed scheme similar to mailto:, tel:, >> sms:, facetime: ? >> >> [1] >> https://developer.apple.com/documentation/xcode/allowing_apps_and_websit= es_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app >> >> >> =E1=90=A7 >> >> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones >> wrote: >> >> You are - that is not standard which is opeind:// >> This is the one step that still needs to be optimized for SIOP to have >> good UX. >> Peace ..tom >> >> >> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote: >> >> Hi Tom >> >> I watched your video (I watched at 2X speed) >> >> Looks like the employment website app that is using localhost:8765 to >> communicate with the wallet. Am I correct? >> >> /Dick >> =E1=90=A7 >> >> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones >> wrote: >> >> Well, here's a demo. Note that in this case the AS is not online all of >> the time, so it is really implicit flow and the OIDC id-token comes from >> the siop device directly. >> (whether this is front-channel or back channel is no longer an >> interesting question.) >> Now if an always-on AS is required, that is possible, but probably beyon= d >> the scope of this effort and would require something like an >> agent-in-the-sky (with diamonds). >> here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 >> >> Peace ..tom >> >> >> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: >> >> Ultimately, in most situations like these in the real world, the hurdle >> isn=E2=80=99t technical compatibility so much as it is trust compatibili= ty. The RP >> (client) needs to have some incentive to trust the assertions and identi= ty >> information that=E2=80=99s coming from the AS. The same is true for an R= S trusting >> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to d= o that (which SSI >> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, >> because it=E2=80=99s a hard question). >> >> Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on >> device=E2=80=9D element. We=E2=80=99ve got the start of it more than OAu= th2/OIDC have by >> allowing the bootstrap of the process from a starting call: the interact= ion >> and continuation URIs handed back by the AS don=E2=80=99t need to be the= same URIs >> that the client starts with, so just like SIOP the process can start in >> HTTP and potentially move to other communication channels. A major >> difference is that we aren=E2=80=99t dependent on the assumption that th= e user will >> always be in a browser at some stage, and so the whole raft of >> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That sai= d, we=E2=80=99ve >> got an opportunity to more explicitly open up alternative communication >> channels here, and that=E2=80=99s something I=E2=80=99d like to see engi= neered, even if >> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal a= s to how that would >> work over specific protocols, starting with what we=E2=80=99ve got today= . >> >> =E2=80=94 Justin >> >> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >> wrote: >> >> Hi Denis, hi Francis, >> >> At some point integration with SSI (on the authentication side) will >> probably occur, including amongst other possibilities SIOP (since they w= ork >> with OpenID a part of the work will probably be made easier). >> >> That being said, Denis is right. It's not an AS. Technically it's >> entirely possible to rely on a decentralized wallet (for instance on you= r >> phone) and a centralized AS. I know of a few studies on how to decentral= ize >> the AS itself (for instance >> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >> Maybe it exists, but I'm still looking for real scenarios (or even >> architectures) where an AS is deployed directly on a phone, and under th= e >> sole authority of the RO, while being compatible with the rest of the >> world. >> >> Cheers, >> Fabien >> >> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >> >> Hello Francis, >> >> See two comments in line. >> >> >> B) Current Document >> >> Roles description shall not hold any assumption on the physical structur= e >> of the party fulfilling the roles. >> [FI] not sure what you mean >> >> [FP] for example, we assume the AS is a server! In most SSI based use >> cases, the AS will be running on the user device. See SIOP ( >> https://identity.foundation/did-siop/). >> >> I browsed through the two drafts, i.e. : >> >> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >> model, and representations W3C Working Draft 08 November 2020 >> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >> Group Draft >> >> At no place within these two documents, it is possible to imagine that >> "the AS will be running on the user device". >> >> From section 3 of the DIF Working Group Draft: >> >> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >> SIOP will not return an access token to the RP". >> >> An Identity Wallet is not an AS. >> >> >> Roles: >> -> grant endpoint of the AS: Why is this a post request? This eliminates >> the chance of having user device hosted AS (no server). >> [FI] what would you propose instead? >> Would also be interested to understand better the deployment model when >> there is no server. That's something that was discussed several times bu= t >> I'm still missing the underlying architecture and use case. >> >> [FP] See above (SIOP). There will be a lot of identity wallets operated >> on end user device. >> >> See the above comment. Please, do not confuse an Identity Wallet with an >> Authentication Server (AS). >> >> Denis >> >> >> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >> request or the access to a resource? >> [FI] yes, we should make the wording clearer >> >> Missing Section Interactions: >> --> This section shall introduce the notion of interaction before we >> start listing interaction types. >> [FI] yes >> >> Interaction Types: >> --> I prefer a classification with Redirect, Decoupled and Embedded is. >> In the draft, we have one redirect and 2 decouple interactions and nothi= ng >> else. >> [FI] this should be handled as a specific discussion item. As a reminder= , >> how would you define embedded? >> >> In practice there's at least these modes: >> - redirect and redirect back >> - redirect to different browser or device >> - user code >> - CIBA >> >> [FP] This classification is limited. >> >> - Redirect: same device, same or different user agents (browser, >> mobile app, desktop app, ...) >> - Decoupled: different devices >> - Embedded : RC carries RO authorization to AS >> >> >> >> Resource Access Request vs. Resource Request >> --> Both are mixed up. No clarification of the context of each section. >> [FI] could you clarify what you'd expect. Btw on this topic, there's a >> more general discussion on whether we should make a distinction or not. >> >> =E2=80=8B[FP]: Here: >> >> - Resource Access Request: Requesting Access to a resource. Response >> is an access token (or any type of grant) >> - Resource Request: Request the resource. Response is the resource >> (or a corresponding execution) >> >> >> Token Content Negotiation >> --> Not expressed as such. This is central to GNAP and not represented >> enough in the document. >> [FI] right. This should be a specific discussion item. >> >> Requesting "User" Information >> we identify two types of users: RQ and RO. It will be better not to refe= r >> to a user in this draft, but either to a RQ or an RO. >> [FI] yes that would avoid potential misunderstandings. Although in the >> end, people will translate RQ into user or end-user most of the time. Cf= in >> definition, currently we have Requesting Party (RQ, aka "user") >> >> >> Interaction Again >> -> For each interaction type, we will have to describe the protocol flow >> and the nature and behavior of involved Roles (Parties), Elements, Reque= sts. >> [FI] yes >> >> >> [FP] Will these and into tickets? >> >> Best regards. >> /Francis >> >> >> >> -- >> 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 >> >> > --000000000000c06fcc05b463f4d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,=C2=A0

As described by Justin= in a previous comment, GNAP already gets us closer to the ultimate goal of= security and privacy. But I'd agree we need to be very pragmatic.=C2= =A0

The issue here, in all cases, is that we'r= e on unchartered=C2=A0territory. And even if we had a solution, it's un= likely most people would be able to implement it, as the underlying framewo= rks (TAPS, DIDComm, etc.) are really early stage.=C2=A0
We alread= y have concerns on how to implement some features in all mainstream languag= es, this would really make it a lot more complicated.
=C2=A0
I would suggest we first focus on designing GNAP around the lines we = know should work well (while still having the idea of future extensions in = mind, of course). There's already a lot to be done.=C2=A0
So = for now, I would keep the hypothesis that the AS is/are server(s) - just no= t limiting to a single AS is not that easy, so we could take it as a first = step.=C2=A0

Last I think we need to keep in mind t= hat GNAP is probably not suitable for end-users directly, one would most pr= obably expect that third-party services still provide the infrastructure. A= nd since the business model around that exists, it also makes the dissemina= tion of GNAP realistic.=C2=A0 =C2=A0

Fabien
<= /div>
O= n Wed, Nov 18, 2020 at 4:49 PM Justin Richer <jricher@mit.edu> wrote:
One of th= e core enhancements of GNAP over OAuth 2 is that the protocol always starts= same way, and we=E2=80=99re doing that by using an HTTP POST request. In O= Auth 2, the client could start off by doing a redirect through the browser = to the authorization endpoint, or calling the token endpoint, or calling th= e device endpoint, or calling the PAR endpoint, or calling the RS (in UMA),= or =E2=80=A6

This is something that GNAP can make bette= r, and in the current design everything starts the same way by calling the = same endpoint, and so it=E2=80=99s always HTTP POST to start.=C2=A0

However, what I was trying to point out earlier in the= thread is that the steps :after: that initial request could move to other = protocols and communication methods, to allow for on-device AS functions on= ce that bootstrap starts things off. So that initial HTTP POST could be han= dled by a surrogate service that will hand off the processing to another sy= stem. That next step, as we=E2=80=99re defining it right now with the =E2= =80=9Ccontinue=E2=80=9D function, is still HTTP and JSON based. But that=E2= =80=99s not to say that an extension could define another response field, s= eparate from =E2=80=9Ccontinue=E2=80=9D, that uses a different communicatio= n mechanism like DIDComm.

I get the desire to have= an abstraction built into the protocol. In my experience with many differe= nt specs over the years, having deep abstractions over one instantiation te= nd to not help, because the abstraction inevitably bakes in a bunch of assu= mptions about the only concrete abstraction and you don=E2=80=99t realize t= hese assumptions are there until you try to add another abstraction. Theref= ore, GNAP is taking the approach of doing a strong binding to HTTP/JSON to = start, and if we can abstract the pieces and concepts and extend beyond tha= t, then we=E2=80=99ll do so when we=E2=80=99ve got items we can abstract ov= er.

=C2=A0=E2=80=94 Justin

On Nov 18, 2020, at 7:46 AM, Fabien Imbault <fabien.imbault@gmail= .com> wrote:

I find the proposal inte= resting. This is achievable for instance by leveraging TAPS=C2=A0htt= ps://tools.ietf.org/html/draft-ietf-taps-arch-09

Yet= , if I remember correctly, the charter states that we rely on HTTP, so I= 9;m not sure we're in the scope.=C2=A0

On Wed, Nov 18, 2020 at 1:0= 6 PM Francis Pouatcha <fpo@adorsys.de> wrote:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"gmail-m_-7182034468501939420gmail-m_4799609422633043705LPlnk338391" tar= get=3D"_blank">https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30= ).

/Francis

From: Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf= .org <txauth@ie= tf.org>; Dick Hardt <dick.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmail.c= om>; Denis <denis.ietf@free.fr>; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrot= e:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org> = on behalf of Dick Hardt <dick.h= ardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; GNAP = Mailing List <txaut= h@ietf.org>; Justin Richer <jri= cher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@g= mail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com>= wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gm= ail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.be/Tq4= hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote= :
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> w= rote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.iet= f.org/html/draft-hardjono-oauth-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possi= ble to imagine that "the AS will be running on the user device".<= br>

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.= Core], the SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity W= allet with an Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



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

--000000000000c06fcc05b463f4d0-- From nobody Wed Nov 18 15:04: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 5E7F63A0DCE for ; Wed, 18 Nov 2020 15:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 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_08=1.651, 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 twJ-IwdIeF7D for ; Wed, 18 Nov 2020 15:04:36 -0800 (PST) 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 EFF6D3A0DCA for ; Wed, 18 Nov 2020 15:04:35 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id i17so4212088ljd.3 for ; Wed, 18 Nov 2020 15:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=6v1sqUlFAkSeUJzaPYjfnvNWYMa56ErR1xucEDUDbRQ=; b=il2/NCY1o0IBnPr9eHAbW2FudwE5gZflaJdZwY+2qTW19b2SYvrD4bMoKPa/jE6Aw4 ixmZ+HySkxWF4Ex3YkJKfdR0MXIfkGPZIVAHZcvZZpnB9ECBbLtfk3slkguRUSuHvhGl VCb9vFNpMSsSd0EwvaHHwcKNCsscCLUDieRJQCa7kYB5W9JPAGfDSHv/BvEalIrIbUuU fTDc0q0cfs77Hv672PBibXb9sCmgSNttyPkQ6WsFmMSWquD443ySer04iXwfFtWy3Hw3 8Rj4q3kYdrZZmpH3y3k2fVbpGckDYSiVbL8rbzu6QmubuO7/lmqJ2zrSns355wrNe/wU A5wQ== 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=6v1sqUlFAkSeUJzaPYjfnvNWYMa56ErR1xucEDUDbRQ=; b=XaiLQ5SLxqYv1BNY+JxMNUbg/L8V2Jbq7W5X3fcjSELm/R0iRf2+A1nTICjABBM2Y3 e1QEKNieU7evVuPEbsbCln+H6g0MX8wap12/l3A0lhfawarA/B2cIU8Y1KBlvDeCu67L wl/T3v93/nEwqJeVhZl19sSIGjTqPpgfRQ6lH9lDzNtaUG7WmevyvHuclTWWiGXi/NVS wn3R3Kp+b5ZGoV6P/xJJtXU3wHQvgLf7gceMcNDSQjnxvrpd9flV7uSSbFmQBHDVqTJS 74JGWFC4Qs8h5KEviPT+nqE0LGXQ//g+O3t+AM2Qs0Nm95KnxvU9CYpKIWDJzI4vhVZ7 pqDg== X-Gm-Message-State: AOAM531jR3duuy37nVrOIbH+wz0sPBPcZlP3I+luUsc8szJxclAFj4YJ OjV1RxedNS2B5IDN079hz/jFXL2f5YdI5+4asRBsV9wke6o= X-Google-Smtp-Source: ABdhPJzsghRWqpzd1ghS6hORgsaZszsdmRvt5vLM+OAeTX8eakBqsbHNFRv9aD3X1avewVbBSZtVGUry36gS3nZrnEs= X-Received: by 2002:a2e:2281:: with SMTP id i123mr4411213lji.246.1605740674104; Wed, 18 Nov 2020 15:04:34 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Wed, 18 Nov 2020 15:03:57 -0800 Message-ID: To: Aaron Parecki Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000007b42e805b469a21f" Archived-At: Subject: [GNAP] security concerns / issues with data in URLs 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, 18 Nov 2020 23:04:37 -0000 --0000000000007b42e805b469a21f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Aaron, In the WG meeting you referenced work in the OAuth WG about removing data that is in URLs for security reaasons. Would you elaborate on what you were referring to? /Dick =E1=90=A7 --0000000000007b42e805b469a21f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Aaron,

In the WG meeting you re= ferenced work in the OAuth WG about removing data that is in URLs for secur= ity reaasons. Would you elaborate on what you were referring to?
=
/Dick
3D""=E1=90=A7
--0000000000007b42e805b469a21f-- From nobody Wed Nov 18 15:38: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 04F813A0E9E for ; Wed, 18 Nov 2020 15:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 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_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=parecki.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 0ImQjj-LN_Gl for ; Wed, 18 Nov 2020 15:38:11 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 43A773A0E96 for ; Wed, 18 Nov 2020 15:38:06 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id h6so3616757ilj.8 for ; Wed, 18 Nov 2020 15:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fMgDDWLOKVW2jVXqvMgqbYJ6/lXUA+NJcnKnaKwvVdU=; b=MHlpjeReZktuHJsm6wnmJtACSY+dDqcVuWTR56eOhjK0tkRXCU252B6SM3d1lwEDWn qV/Aw17a7GEuOVk5o64B5zjabPZEG5OyatdjzrDrbeasXWQsmxaQk8mD9hD2VwW8vGBg +R7RnRIvmoiuxYUrcJui6d3eE8X37Is5Mo02k4hi6gjG4U5uZ6gHsW/wa+gZR/HOYc0u C6TLHJ9l5pQzG4syh4Bw5RZe+C9Bpww4WjGrWIXLoZuMN2Dv4TJ4PxYDUX1DO9XnPt/r 1S6SZ5/8MzQu3WeQbqtTGYgPNAYsBi7S7fzvwriadQ9boRtWudTO+tf9alI7gNMp8dj5 iGOQ== 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=fMgDDWLOKVW2jVXqvMgqbYJ6/lXUA+NJcnKnaKwvVdU=; b=KlgnhHn6ztSr07qnjgZia8/bhn7lWQTxkNpglxAWyDKSpzlz5DiKM4k6rt6MPQ1j0r 0Fc72p5rH4cbb4BbV7CgQrMFMMpmwBYJWXU4VguA1wqOm8BXKz/Eo7W0Yr4QrK/iCjtJ +yYNrBJGnS8oBEHNeFiUyJiCBe4OQJofZvLSNh75Ys/EGI/8yVJt8fld1aUwSJqIh3BJ yj3zLxvK5O7SLfjLtL9HN8O3Brc4X/zMGc4QXEsHjdATIXfhyLC2SFwQ4u18I3vgX+F3 E+PkSZawYwUoWKyXisl3qlfJLcHVvtmsEb+w7le7GDvoxK6Dzsv86xEJLFUaLZXPepE3 9eaQ== X-Gm-Message-State: AOAM531vHi/nWgRxi2btIQThsQdUGKC2skKYOlfd9obprFymONisqXLG Wtkud0XiDF/bYMLY3jhShamgZoIOhnraBg== X-Google-Smtp-Source: ABdhPJwXwjGGXGBmdsmpgJJk/JBDYu503C5KUa/magepf5bqfmXGOxuNJap5c1hULtKx8hz+3mawnQ== X-Received: by 2002:a05:6e02:d0e:: with SMTP id g14mr19679475ilj.48.1605742684405; Wed, 18 Nov 2020 15:38:04 -0800 (PST) Received: from mail-il1-f171.google.com (mail-il1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id j12sm12654735iow.27.2020.11.18.15.38.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Nov 2020 15:38:03 -0800 (PST) Received: by mail-il1-f171.google.com with SMTP id l12so3670194ilo.1 for ; Wed, 18 Nov 2020 15:38:02 -0800 (PST) X-Received: by 2002:a92:c213:: with SMTP id j19mr20233948ilo.255.1605742682463; Wed, 18 Nov 2020 15:38:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Wed, 18 Nov 2020 15:38:02 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000030658605b46a1a3e" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 18 Nov 2020 23:38:16 -0000 --00000000000030658605b46a1a3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was referring to the work being done to reduce the reliance on the front channel: * Dropping the Implicit grant * Adding PAR to initiate an OAuth request from a POST request instead of GE= T --- Aaron Parecki https://aaronparecki.com On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt wrote: > Hey Aaron, > > In the WG meeting you referenced work in the OAuth WG about removing data > that is in URLs for security reaasons. Would you elaborate on what you we= re > referring to? > > /Dick > =E1=90=A7 > --00000000000030658605b46a1a3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was referring to the work being done to reduce the relia= nce on the front channel:

* Dropping the Implicit grant<= /div>
* Adding PAR to initiate an OAuth request from a POST request ins= tead of GET

---
Aaro= n Parecki


On Wed, Nov 18= , 2020 at 3:04 PM Dick Hardt <di= ck.hardt@gmail.com> wrote:
Hey Aaron,

In the= WG meeting you referenced work in the OAuth WG about removing data that is= in URLs for security reaasons. Would you elaborate on what you were referr= ing to?

/Dick
3D""=E1=90= =A7
--00000000000030658605b46a1a3e-- From nobody Wed Nov 18 17:05: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 8F9E43A1094 for ; Wed, 18 Nov 2020 17:05:15 -0800 (PST) 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 GXMAX2a-IBzh for ; Wed, 18 Nov 2020 17:05:14 -0800 (PST) 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 055743A1093 for ; Wed, 18 Nov 2020 17:05:13 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id u19so5796293lfr.7 for ; Wed, 18 Nov 2020 17:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cjdLnxLM+GxviJ/LQvobw2P4LMhxqUdVjfhRMjjZPgs=; b=vIn05qmMsRsCP5FfjjXr7nUXj6AJkhbqtYTpkhOjtaaVoK/E8whmseeAhQ14w7ZU+V sWT24ezIOSm5VWbOt7Qw73jf69/cva+lbPDpkhmUYdG+9MRbtPhpp52Wa6TWjAMcA/nE v6MPiSvlhPzPoDqFSRED/ftww5irp32NH/cA21g1F6M398pI2E8eT7odZ2RjKz1lX+KW s+cuoWZInCW4wzKhwMqOOiTilaGMId6iGHxFuoBX+frM1OYUNOSeskMF1IzsxOJUwEbC F9lzGQ3seyWl9cG3B7IqIJZc5KwnibEQEhbPemt9epPDEa0aId9sYzfYf0XAHj0C8l+s E99w== 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=cjdLnxLM+GxviJ/LQvobw2P4LMhxqUdVjfhRMjjZPgs=; b=Fi9c2IIfX6toXVSLYl6e2atozdfFrnIzVsf4TsKePkXneoYfpEekT0RxtWhdI2D/qN OecUT0Q1N2JWbrDtA29TVGgpItDKCQ6z0MReOljI5djX/zrJzhWp+D5NaS2ayAmQ7hFr /si/WiHR+QmuFakh1SdAZbpdXwifmonCXz0LiB7tI2JY5oXNqLr87Cg7JwSbvfDPUgmv ZC6UNj2/9fflYKLSpP5KTvYshWVMdaXxzOfi3cZNZwZBc/f2QKkAw7SOcR7NM92P4d02 odPjAhxR5B84AsZwqxy7C7JmVO4Eu1G+oS3rBQO7nLmfgoIQK8FINJXU/SrSrFmrOKrV 3NVQ== X-Gm-Message-State: AOAM531XGPGAiC/KjiX4sIAdNpRNC9di+0RMiyBbQG8OgGoFrw79/wH8 G7xuiCqx0dAav4VVUStyDMDcKCAw05QBtB22kpM= X-Google-Smtp-Source: ABdhPJxBD7igaYBlc4eXDX6McONsNuQEDviUtd2L/Zy5wHO1MFkLRBX44jqkhuTTJbHGJ7cA+gozqOPcb8Du/PqPiRc= X-Received: by 2002:a05:6512:3137:: with SMTP id p23mr4464068lfd.67.1605747911683; Wed, 18 Nov 2020 17:05:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 18 Nov 2020 17:04:35 -0800 Message-ID: To: Aaron Parecki Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000dff1ec05b46b5115" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 19 Nov 2020 01:05:16 -0000 --000000000000dff1ec05b46b5115 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Got it, thanks! As we know, there is no certainty of who the originator of a redirect was, and there is no assurance about the integrity or secrecy of the URL contents. Those are not the case in GNAP with the client calling the AS -- so what is the risk of having information in the URL? You had mentioned the information leaking into logs -- but the AS controls those logs -- and the logs are a concern, the AS could put an encrypted token in the URL. =E1=90=A7 On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki wrote: > I was referring to the work being done to reduce the reliance on the fron= t > channel: > > * Dropping the Implicit grant > * Adding PAR to initiate an OAuth request from a POST request instead of > GET > > --- > Aaron Parecki > https://aaronparecki.com > > > On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt wrote: > >> Hey Aaron, >> >> In the WG meeting you referenced work in the OAuth WG about removing dat= a >> that is in URLs for security reaasons. Would you elaborate on what you w= ere >> referring to? >> >> /Dick >> =E1=90=A7 >> > --000000000000dff1ec05b46b5115 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got it, thanks!

As we know, there is no= certainty of who the originator=C2=A0of a redirect was, and there is no as= surance about the integrity or secrecy of the URL contents.

<= /div>
Those are not the case in GNAP with the client calling the AS -- = so what is the risk of having information in the URL?

<= div>You had mentioned the information=C2=A0leaking into logs -- but the AS = controls those logs -- and the=C2=A0logs are a=C2=A0concern, the=C2=A0AS co= uld put an encrypted token in the URL.=C2=A0

3D""=E1=90=A7
On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki <aaron@parecki.com> wrote:
I was = referring to the work being done to reduce the reliance on the front channe= l:

* Dropping the Implicit grant
* Adding PAR = to initiate an OAuth request from a POST request instead of GET
<= br>
---
Aaron Parecki=


On Wed, Nov 18, 2020 at= 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Aaron,

In the WG meeting you referenced work in the OAuth WG about removing dat= a that is in URLs for security reaasons. Would you elaborate on what you we= re referring to?

/Dick
3D""=E1=90=A7
--000000000000dff1ec05b46b5115-- From nobody Wed Nov 18 21:24: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 CEC933A0D79 for ; Wed, 18 Nov 2020 21:24:16 -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 ik3BXoLEtJWQ for ; Wed, 18 Nov 2020 21:24:14 -0800 (PST) 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 EF1FF3A0EE4 for ; Wed, 18 Nov 2020 21:23:52 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id k3so4174734otp.12 for ; Wed, 18 Nov 2020 21:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=URBxKLrQXLRCr/gaME4O/mEM2Qs0Y/yWe5wXUAg20nU=; b=KQTH++nSTOYVxNR8NURQbWPWikFaAxOITvuNkx0k/o4nNxUNbobN0m+Ac36rNnltoe 1geSguFaoBX95lzAwQZOD6zemM/MF4zQSC3YVCWfgO9ba0jf+aU5+P28r/x3WkbmMK9Q oTGIE8U3wF+5PjfZ2WS2cU2ao49ZBMrwwOwR7Z+T7d/goHbGFrcK2TI2FDYRqe+enYzZ Gyj0FjmmGWKH7Cd7uJKvjW4HYPYnfT0AyYJKBcb3PhwYzGjLY2LNSSKIax7jS7+9qqen EvBaAIQtFMPR+m3jVJixYHMc20AwzoNPdg0OfGmYrHobaCgxU8kzFcHdFFj3cX7gDSpk 68vQ== 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=URBxKLrQXLRCr/gaME4O/mEM2Qs0Y/yWe5wXUAg20nU=; b=U+6sQr8gUUQSl5gJgbaExu4F5ifEjOM0MZxFfgfuz1KYcVdwPOrYmDWHPxQUrVnwsX Fdv93B/RcIYr8+FcicS7ne9zYeiA7m2kSS9SgrkQscXnC6Wy01tut4MMMPMy6kovpoqF fXdK4VaYDH1ZXc0zx0yoc3HZVumUVFZP0fe0YzZW0cQpvMrVoJJtRz2FV7O/88mwdwBm Qm96ZfXArg8Ec0Ub8yF1Tbj4/SDQRXmed74/dgGXcGFpTGIYVsLdvS7NfmewCnymQtXp Us4q+DXCWmJwcsZniu4PMwSEnrs7t0steRcF1J+NNTc+aqFtKXnUd42ty6L3AnzJpRB9 qvVA== X-Gm-Message-State: AOAM530sN4PQRNq/0e+jcbcSoWj4Z5m/1EkzwD8mib28T80Ev75j+oBV GtpdQ/aTiqbJtPJ9JptsOxer10XE7F8YwrXFvn4= X-Google-Smtp-Source: ABdhPJyNGsuOFHYb/azmi1wtlxdX0VaduGZRtSpb55qOnIiXJkyju4y5koVBDvPjrI6J5nxpLOfXmUhtCXh397pdLdU= X-Received: by 2002:a05:6830:1af7:: with SMTP id c23mr8527718otd.358.1605763432175; Wed, 18 Nov 2020 21:23:52 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> From: Tom Jones Date: Wed, 18 Nov 2020 21:23:40 -0800 Message-ID: To: Justin Richer Cc: Fabien Imbault , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000f7dddc05b46eeeb6" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 19 Nov 2020 05:24:17 -0000 --000000000000f7dddc05b46eeeb6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually that's not the hard problem, which is, once the user wanders off on some path that is not anchored in the browser, how does the path get back to the same place in the browser? This is "straightforward" when the path from siop to some url in the cloud is completely separated from the path between the user and the client, but that is not the path usually taken. We need some new entity to pull this off. Call it the AS proxy if you will. The problem I have with that is who is going to pay the AS proxy? If I can figure that payment issue out, I think I can complete the rest of the flows. Peace ..tom On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: > Ultimately, in most situations like these in the real world, the hurdle > isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP > (client) needs to have some incentive to trust the assertions and identit= y > information that=E2=80=99s coming from the AS. The same is true for an RS= trusting > tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to do= that (which SSI > answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, > because it=E2=80=99s a hard question). > > Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on device=E2=80=9D > element. We=E2=80=99ve got the start of it more than OAuth2/OIDC have by = allowing > the bootstrap of the process from a starting call: the interaction and > continuation URIs handed back by the AS don=E2=80=99t need to be the same= URIs that > the client starts with, so just like SIOP the process can start in HTTP a= nd > potentially move to other communication channels. A major difference is > that we aren=E2=80=99t dependent on the assumption that the user will alw= ays be in > a browser at some stage, and so the whole raft of front-channel messages > that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an = opportunity to > more explicitly open up alternative communication channels here, and that= =E2=80=99s > something I=E2=80=99d like to see engineered, even if it=E2=80=99s an ext= ension. I=E2=80=99d love > to see a concrete proposal as to how that would work over specific > protocols, starting with what we=E2=80=99ve got today. > > =E2=80=94 Justin > > On Nov 17, 2020, at 12:03 PM, Fabien Imbault > wrote: > > Hi Denis, hi Francis, > > At some point integration with SSI (on the authentication side) will > probably occur, including amongst other possibilities SIOP (since they wo= rk > with OpenID a part of the work will probably be made easier). > > That being said, Denis is right. It's not an AS. Technically it's entirel= y > possible to rely on a decentralized wallet (for instance on your phone) a= nd > a centralized AS. I know of a few studies on how to decentralize the AS > itself (for instance > https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). > Maybe it exists, but I'm still looking for real scenarios (or even > architectures) where an AS is deployed directly on a phone, and under the > sole authority of the RO, while being compatible with the rest of the > world. > > Cheers, > Fabien > > On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: > >> Hello Francis, >> >> See two comments in line. >> >> >> B) Current Document >> >> Roles description shall not hold any assumption on the physical structur= e >> of the party fulfilling the roles. >> [FI] not sure what you mean >> >> [FP] for example, we assume the AS is a server! In most SSI based use >> cases, the AS will be running on the user device. See SIOP ( >> https://identity.foundation/did-siop/). >> >> I browsed through the two drafts, i.e. : >> >> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >> model, and representations W3C Working Draft 08 November 2020 >> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >> Group Draft >> >> At no place within these two documents, it is possible to imagine that >> "the AS will be running on the user device". >> >> From section 3 of the DIF Working Group Draft: >> >> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >> SIOP will not return an access token to the RP". >> >> An Identity Wallet is not an AS. >> >> >> Roles: >> -> grant endpoint of the AS: Why is this a post request? This eliminates >> the chance of having user device hosted AS (no server). >> [FI] what would you propose instead? >> Would also be interested to understand better the deployment model when >> there is no server. That's something that was discussed several times bu= t >> I'm still missing the underlying architecture and use case. >> >> [FP] See above (SIOP). There will be a lot of identity wallets operated >> on end user device. >> >> See the above comment. Please, do not confuse an Identity Wallet with an >> Authentication Server (AS). >> >> Denis >> >> >> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >> request or the access to a resource? >> [FI] yes, we should make the wording clearer >> >> Missing Section Interactions: >> --> This section shall introduce the notion of interaction before we >> start listing interaction types. >> [FI] yes >> >> Interaction Types: >> --> I prefer a classification with Redirect, Decoupled and Embedded is. >> In the draft, we have one redirect and 2 decouple interactions and nothi= ng >> else. >> [FI] this should be handled as a specific discussion item. As a reminder= , >> how would you define embedded? >> >> In practice there's at least these modes: >> - redirect and redirect back >> - redirect to different browser or device >> - user code >> - CIBA >> >> [FP] This classification is limited. >> >> - Redirect: same device, same or different user agents (browser, >> mobile app, desktop app, ...) >> - Decoupled: different devices >> - Embedded : RC carries RO authorization to AS >> >> >> >> Resource Access Request vs. Resource Request >> --> Both are mixed up. No clarification of the context of each section. >> [FI] could you clarify what you'd expect. Btw on this topic, there's a >> more general discussion on whether we should make a distinction or not. >> >> =E2=80=8B[FP]: Here: >> >> - Resource Access Request: Requesting Access to a resource. Response >> is an access token (or any type of grant) >> - Resource Request: Request the resource. Response is the resource >> (or a corresponding execution) >> >> >> Token Content Negotiation >> --> Not expressed as such. This is central to GNAP and not represented >> enough in the document. >> [FI] right. This should be a specific discussion item. >> >> Requesting "User" Information >> we identify two types of users: RQ and RO. It will be better not to refe= r >> to a user in this draft, but either to a RQ or an RO. >> [FI] yes that would avoid potential misunderstandings. Although in the >> end, people will translate RQ into user or end-user most of the time. Cf= in >> definition, currently we have Requesting Party (RQ, aka "user") >> >> >> Interaction Again >> -> For each interaction type, we will have to describe the protocol flow >> and the nature and behavior of involved Roles (Parties), Elements, Reque= sts. >> [FI] yes >> >> >> [FP] Will these and into tickets? >> >> Best regards. >> /Francis >> >> >> >> -- >> 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 > --000000000000f7dddc05b46eeeb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Actually that's not the hard problem, which is, once t= he user wanders off on some path that is not anchored in the browser, how d= oes the path get back to the same place in the browser?
This is "s= traightforward" when the path from siop to some url in the cloud is co= mpletely separated from the path between the user and the client, but that = is not the path usually taken.
We need some new entity to pull th= is off. Call it the AS proxy if you will. The problem I have with that is w= ho is going to pay the AS proxy?
If I can figure that payment iss= ue out, I think I can complete the rest of the flows.

Peace ..tom
<= br>

On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdle is= n=E2=80=99t technical compatibility so much as it is trust compatibility. T= he RP (client) needs to have some incentive to trust the assertions and ide= ntity information that=E2=80=99s coming from the AS. The same is true for a= n RS trusting tokens from the AS. The hard question is less =E2=80=9Chow=E2= =80=9D to do that (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do= that (which SSI doesn=E2=80=99t answer very well, because it=E2=80=99s a h= ard question).

Still: it=E2=80=99s definitely a question= about how to support this =E2=80=9CAS on device=E2=80=9D element. We=E2=80= =99ve got the start of it more than OAuth2/OIDC have by allowing the bootst= rap of the process from a starting call: the interaction and continuation U= RIs handed back by the AS don=E2=80=99t need to be the same URIs that the c= lient starts with, so just like SIOP the process can start in HTTP and pote= ntially move to other communication channels. A major difference is that we= aren=E2=80=99t dependent on the assumption that the user will always be in= a browser at some stage, and so the whole raft of front-channel messages t= hat SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an opp= ortunity to more explicitly open up alternative communication channels here= , and that=E2=80=99s something I=E2=80=99d like to see engineered, even if = it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal as t= o how that would work over specific protocols, starting with what we=E2=80= =99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin
<= div>
On Nov 17, 2020, at 12:03 PM, Fabien= Imbault <= fabien.imbault@gmail.com> wrote:

Hi D= enis, hi Francis,=C2=A0

At some point integration with S= SI (on the authentication side) will probably occur, including amongst othe= r possibilities SIOP (since they work with OpenID a part of the work will p= robably be made easier).=C2=A0

That being said, De= nis is right. It's not an AS. Technically it's entirely possible to= rely on a decentralized wallet (for instance on your phone) and a centrali= zed AS. I know of a few studies on how to decentralize the AS itself (for i= nstance=C2=A0https://tools.ietf.org/html/draft-hardjon= o-oauth-decentralized-02).
Maybe it exists, but I'm still= looking for real scenarios (or even architectures) where an AS is deployed= directly on a phone, and under the sole authority of the RO, while being c= ompatible with the rest of the world.=C2=A0

Cheers= ,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr>= wrote:
=20 =20 =20
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
=C2=A0[FP] for example, we assume the AS is a server! In mo= st SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagi= ne that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP"= .

An Identity Wallet is not an AS.


Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
=C2=A0[FP] See above (SIOP). There will be a lot of identit= y wallets operated on end user device.

See the above comment. Please, do not confuse an Identi= ty Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes=C2= =A0

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code=
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could yo= u clarify what you'd expect.=C2=A0 Btw on this topic, there's a more general discussion on whether we should make a distinction or not.=C2=A0
=E2=80=8B[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a specific discussion item.=C2=A0=

Requesting "User&quo= t; Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user=C2=A0or end-user most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes=C2= =A0=C2=A0

[FP] Will these and into tickets?

Best regards.
/Francis



--
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
--000000000000f7dddc05b46eeeb6-- From nobody Wed Nov 18 22:14:32 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 7229F3A0E5C for ; Wed, 18 Nov 2020 22:14:31 -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 Fjty2GhL_PUI for ; Wed, 18 Nov 2020 22:14:28 -0800 (PST) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0: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 264FC3A0EBE for ; Wed, 18 Nov 2020 22:13:47 -0800 (PST) Received: by mail-il1-x131.google.com with SMTP id l13so4295457ilg.3 for ; Wed, 18 Nov 2020 22:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eHST0+LRLZAwdX89mjxL4nJVA0IvRdp6xuCFMAwbr0g=; b=iWQI0GJRpCj2ZoAxpBQSG4zqUGwM1jV3yMj1ntlfH6kdpk8F71zigZQD7sIq7FCrRg z7HNfXP2O7BuS4/O2lSf4NCVXB+QSUWRMxflkGFpYOlhzRuw9KricgCskqQShB5C363L +i1sHh/xq2dxPPa4UTxJcEnz2MExrO1cNJlHC7cb6prnb64P0Rg7gtosFey6TIEFmcMY Mxq6+H4nYjkSKn7zxMkRauyfjlNIBu2vmgpu6tCyAVEGu2Bkcgn9syt88b+yBuitDMhR N1/rJ5tVS7lrbYRV3DBI9gfS/XIlKxPylui2449PIYcgxUr/hNoLZnoTFQ8DwFHIMKun EADg== 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=eHST0+LRLZAwdX89mjxL4nJVA0IvRdp6xuCFMAwbr0g=; b=AZKZIhp4zNW3HziATOoSYDqEX2NYPIVNeaNnH3jdk7JvHyS4j7YkokPT++8u0py01s rNAMDbU6C9lnR1ziUZeFMT/bmxf1uvizn8mQ+p2Gafz57e+xLIQieVjGReo/HJ04TQKK 8IYbrsOM333U/4hc6l6DjqyL/a+RKh8uiyRcqEZpdiE9OuuLrJsKF7vbjmmnLt+TZS3q 7SJEg5kmJYXo8bF2P3rY3Bd9kcbabxv31skq/bFZa465NcXcCG3U7TLL8z3lvqQUi8Fu +XMp8ihmpd+H3fldnWudLyyXYrZBL/7qsuVJfGFXHGcB8/VCyDUJMAtrN5CXQdhpVc9E a7Xw== X-Gm-Message-State: AOAM530GgpTsUvaXuLpyqKMhRvrY+EJE3EpKyxLwYkicn4SfuFHzWJo4 po9pceB4WcVlTzPM9M8GbjVfrAK0Zou5Mq/kXZlhW9SJS4gF1A== X-Google-Smtp-Source: ABdhPJyhfzmU381rCpA1EsM1p/+GGgxu7b1df8rIW0DlritjRwdfFMMIorT9OfdHFetcsCE7bC3ZyohAWXgP39BGfGk= X-Received: by 2002:a92:89d3:: with SMTP id w80mr18322625ilk.68.1605766426366; Wed, 18 Nov 2020 22:13:46 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 19 Nov 2020 07:13:34 +0100 Message-ID: To: Tom Jones Cc: Justin Richer , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000006f9a3005b46fa1ac" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 19 Nov 2020 06:14:32 -0000 --0000000000006f9a3005b46fa1ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, My answer is completely speculative. But I guess it would probably involve the end-user paying to some sort of service provider (just like one pays for having a VPN). With the same potential risks (i.e free tiers that serve ads or resell your data, or limit volumes of connections)? Cheers Fabien Le jeu. 19 nov. 2020 =C3=A0 06:23, Tom Jones = a =C3=A9crit : > Actually that's not the hard problem, which is, once the user wanders off > on some path that is not anchored in the browser, how does the path get > back to the same place in the browser? > This is "straightforward" when the path from siop to some url in the clou= d > is completely separated from the path between the user and the client, bu= t > that is not the path usually taken. > We need some new entity to pull this off. Call it the AS proxy if you > will. The problem I have with that is who is going to pay the AS proxy? > If I can figure that payment issue out, I think I can complete the rest o= f > the flows. > > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: > >> Ultimately, in most situations like these in the real world, the hurdle >> isn=E2=80=99t technical compatibility so much as it is trust compatibili= ty. The RP >> (client) needs to have some incentive to trust the assertions and identi= ty >> information that=E2=80=99s coming from the AS. The same is true for an R= S trusting >> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to d= o that (which SSI >> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, >> because it=E2=80=99s a hard question). >> >> Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on >> device=E2=80=9D element. We=E2=80=99ve got the start of it more than OAu= th2/OIDC have by >> allowing the bootstrap of the process from a starting call: the interact= ion >> and continuation URIs handed back by the AS don=E2=80=99t need to be the= same URIs >> that the client starts with, so just like SIOP the process can start in >> HTTP and potentially move to other communication channels. A major >> difference is that we aren=E2=80=99t dependent on the assumption that th= e user will >> always be in a browser at some stage, and so the whole raft of >> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That sai= d, we=E2=80=99ve >> got an opportunity to more explicitly open up alternative communication >> channels here, and that=E2=80=99s something I=E2=80=99d like to see engi= neered, even if >> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal a= s to how that would >> work over specific protocols, starting with what we=E2=80=99ve got today= . >> >> =E2=80=94 Justin >> >> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >> wrote: >> >> Hi Denis, hi Francis, >> >> At some point integration with SSI (on the authentication side) will >> probably occur, including amongst other possibilities SIOP (since they w= ork >> with OpenID a part of the work will probably be made easier). >> >> That being said, Denis is right. It's not an AS. Technically it's >> entirely possible to rely on a decentralized wallet (for instance on you= r >> phone) and a centralized AS. I know of a few studies on how to decentral= ize >> the AS itself (for instance >> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >> Maybe it exists, but I'm still looking for real scenarios (or even >> architectures) where an AS is deployed directly on a phone, and under th= e >> sole authority of the RO, while being compatible with the rest of the >> world. >> >> Cheers, >> Fabien >> >> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >> >>> Hello Francis, >>> >>> See two comments in line. >>> >>> >>> B) Current Document >>> >>> Roles description shall not hold any assumption on the physical >>> structure of the party fulfilling the roles. >>> [FI] not sure what you mean >>> >>> [FP] for example, we assume the AS is a server! In most SSI based use >>> cases, the AS will be running on the user device. See SIOP ( >>> https://identity.foundation/did-siop/). >>> >>> I browsed through the two drafts, i.e. : >>> >>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>> model, and representations W3C Working Draft 08 November 2020 >>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >>> Group Draft >>> >>> At no place within these two documents, it is possible to imagine that >>> "the AS will be running on the user device". >>> >>> From section 3 of the DIF Working Group Draft: >>> >>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >>> SIOP will not return an access token to the RP". >>> >>> An Identity Wallet is not an AS. >>> >>> >>> Roles: >>> -> grant endpoint of the AS: Why is this a post request? This eliminate= s >>> the chance of having user device hosted AS (no server). >>> [FI] what would you propose instead? >>> Would also be interested to understand better the deployment model when >>> there is no server. That's something that was discussed several times b= ut >>> I'm still missing the underlying architecture and use case. >>> >>> [FP] See above (SIOP). There will be a lot of identity wallets operate= d >>> on end user device. >>> >>> See the above comment. Please, do not confuse an Identity Wallet with a= n >>> Authentication Server (AS). >>> >>> Denis >>> >>> >>> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >>> request or the access to a resource? >>> [FI] yes, we should make the wording clearer >>> >>> Missing Section Interactions: >>> --> This section shall introduce the notion of interaction before we >>> start listing interaction types. >>> [FI] yes >>> >>> Interaction Types: >>> --> I prefer a classification with Redirect, Decoupled and Embedded is. >>> In the draft, we have one redirect and 2 decouple interactions and noth= ing >>> else. >>> [FI] this should be handled as a specific discussion item. As a >>> reminder, how would you define embedded? >>> >>> In practice there's at least these modes: >>> - redirect and redirect back >>> - redirect to different browser or device >>> - user code >>> - CIBA >>> >>> [FP] This classification is limited. >>> >>> - Redirect: same device, same or different user agents (browser, >>> mobile app, desktop app, ...) >>> - Decoupled: different devices >>> - Embedded : RC carries RO authorization to AS >>> >>> >>> >>> Resource Access Request vs. Resource Request >>> --> Both are mixed up. No clarification of the context of each section. >>> [FI] could you clarify what you'd expect. Btw on this topic, there's a >>> more general discussion on whether we should make a distinction or not. >>> >>> =E2=80=8B[FP]: Here: >>> >>> - Resource Access Request: Requesting Access to a resource. Response >>> is an access token (or any type of grant) >>> - Resource Request: Request the resource. Response is the resource >>> (or a corresponding execution) >>> >>> >>> Token Content Negotiation >>> --> Not expressed as such. This is central to GNAP and not represented >>> enough in the document. >>> [FI] right. This should be a specific discussion item. >>> >>> Requesting "User" Information >>> we identify two types of users: RQ and RO. It will be better not to >>> refer to a user in this draft, but either to a RQ or an RO. >>> [FI] yes that would avoid potential misunderstandings. Although in the >>> end, people will translate RQ into user or end-user most of the time. C= f in >>> definition, currently we have Requesting Party (RQ, aka "user") >>> >>> >>> Interaction Again >>> -> For each interaction type, we will have to describe the protocol flo= w >>> and the nature and behavior of involved Roles (Parties), Elements, Requ= ests. >>> [FI] yes >>> >>> >>> [FP] Will these and into tickets? >>> >>> Best regards. >>> /Francis >>> >>> >>> >>> -- >>> 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 >> > --0000000000006f9a3005b46fa1ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

My a= nswer is completely speculative.=C2=A0
But I guess i= t would probably involve the end-user paying to some sort of service provid= er (just like one pays for having a VPN). With the same potential risks (i.= e free tiers that serve ads or resell your data, or limit volumes of connec= tions)?=C2=A0

Cheers
Fabien=C2=A0


Le jeu. 19 nov. 2020 =C3= =A0 06:23, Tom Jones <thomasclinganjones= @gmail.com> a =C3=A9crit=C2=A0:
Actually that's not the hard problem, which is, on= ce the user wanders off on some path that is not anchored in the browser, h= ow does the path get back to the same place in the browser?
This is &qu= ot;straightforward" when the path from siop to some url in the cloud i= s completely separated from the path between the user and the client, but t= hat is not the path usually taken.
We need some new entity to pul= l this off. Call it the AS proxy if you will. The problem I have with that = is who is going to pay the AS proxy?
If I can figure that payment= issue out, I think I can complete the rest of the flows.

Peace ..tom


On Tue, Nov 17,= 2020 at 9:20 AM Justin Richer <jricher@= mit.edu> wrote:
Ultimately, in most situations like these in the real world, th= e hurdle isn=E2=80=99t technical compatibility so much as it is trust compa= tibility. The RP (client) needs to have some incentive to trust the asserti= ons and identity information that=E2=80=99s coming from the AS. The same is= true for an RS trusting tokens from the AS. The hard question is less =E2= =80=9Chow=E2=80=9D to do that (which SSI answers), but more =E2=80=9Cwhy=E2= =80=9D to do that (which SSI doesn=E2=80=99t answer very well, because it= =E2=80=99s a hard question).

Still: it=E2=80=99s definit= ely a question about how to support this =E2=80=9CAS on device=E2=80=9D ele= ment. We=E2=80=99ve got the start of it more than OAuth2/OIDC have by allow= ing the bootstrap of the process from a starting call: the interaction and = continuation URIs handed back by the AS don=E2=80=99t need to be the same U= RIs that the client starts with, so just like SIOP the process can start in= HTTP and potentially move to other communication channels. A major differe= nce is that we aren=E2=80=99t dependent on the assumption that the user wil= l always be in a browser at some stage, and so the whole raft of front-chan= nel messages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80= =99ve got an opportunity to more explicitly open up alternative communicati= on channels here, and that=E2=80=99s something I=E2=80=99d like to see engi= neered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concre= te proposal as to how that would work over specific protocols, starting wit= h what we=E2=80=99ve got today.=C2=A0

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

On Nov 17, 2020, at 1= 2:03 PM, Fabien Imbault <fabien.i= mbault@gmail.com> wrote:

Hi Denis, hi= Francis,=C2=A0

At some point integration with SSI (on t= he authentication side) will probably occur, including amongst other possib= ilities SIOP (since they work with OpenID a part of the work will probably = be made easier).=C2=A0

That being said, Denis is r= ight. It's not an AS. Technically it's entirely possible to rely on= a decentralized wallet (for instance on your phone) and a centralized AS. = I know of a few studies on how to decentralize the AS itself (for instance= =C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02).=
Maybe it exists, but I'm still looking for real scenarios (o= r even architectures) where an AS is deployed directly on a phone, and unde= r the sole authority of the RO, while being compatible with the rest of the= world.=C2=A0

Cheers,
Fabien
=
On Tue= , Nov 17, 2020 at 5:45 PM Denis <denis.= ietf@free.fr> wrote:
=20 =20 =20
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
=C2=A0[FP] for example, we assume the AS is a server! In mo= st SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/di= d-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagi= ne that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP"= .

An Identity Wallet is not an AS.


Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
=C2=A0[FP] See above (SIOP). There will be a lot of identit= y wallets operated on end user device.

See the above comment. Please, do not confuse an Identi= ty Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes=C2= =A0

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code=
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could yo= u clarify what you'd expect.=C2=A0 Btw on this topic, there's a more general discussion on whether we should make a distinction or not.=C2=A0
=E2=80=8B[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a specific discussion item.=C2=A0=

Requesting "User&quo= t; Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user=C2=A0or end-user most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes=C2= =A0=C2=A0

[FP] Will these and into tickets?

Best regards.
/Francis



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

--
TXAuth mailing list
TXAuth@ietf.org
https://www.= ietf.org/mailman/listinfo/txauth
--0000000000006f9a3005b46fa1ac-- From nobody Thu Nov 19 01:37: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 198933A12C3 for ; Thu, 19 Nov 2020 01:37:03 -0800 (PST) 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, NICE_REPLY_A=-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 WOh-v_n3kBjq for ; Thu, 19 Nov 2020 01:37:00 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873773A12C5 for ; Thu, 19 Nov 2020 01:36:58 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id d17so7249559lfq.10 for ; Thu, 19 Nov 2020 01:36:58 -0800 (PST) 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=v279zu1PUEmuoSfj3l+Fr09yrroCljb/WIVmHbr2KPI=; b=Npio2w1bVeWN14Yteft8tsaEPAgHVHGEWgrhW4AHeFPhsHXvP2rtjAUd6J41woi1pX lcNotteUQ/VJARStffp+KXjgdSDAmxnVJ3a429eHR1xNWx77KP6SK5+9Hc5y2N2Zu1AU A4wpFRmRkJXhX7PW0Inu9dXievLFLCeiI2Why7/aTsgV34VvZIfxeDjQqo7WYpDY8Rdj srRy+56ALyQsbaYydBa11eDFzoUqsaiYgjjVwSWxvwNWy1t+Z+J/XBoRXV+8bTSfYzJQ BrmebqqclCSq2w7/B+Bko6zIYuTzy/YgYHnhh5ZyOM8r/vQgNXLC6ioTny/h/o4OMaYX +cUQ== 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=v279zu1PUEmuoSfj3l+Fr09yrroCljb/WIVmHbr2KPI=; b=cN/OSdkGEw7p419ar2L8xKKpShbSZzmbzs0Ez088O9YoOB6Y3BXo1KPa+ujnf5XgFm RMNK5jG7rzG5IkTFBZd7GblLIC6mWNDvyH8GMnzMbqID6apsXoZUctIAUizak6F46fYb /CXR3BOnq486AzLvBbFnRyPDAJNf+Dbtp0CRRt7gKZoDllESMQu7J2AZlfv0Q+FpLbRv Amm2vEnimfQDftVJer6ngM5hajC41Sxf9rj5dXZoILbM2ixgOa8POfxnwMR5YFFBinQ5 GerWCBOswugfaAP8a3uCktIFfBkubaKv24g1WFZz8ppHZ0xvcJbBkbulSvdgFjOzkS17 ZApw== X-Gm-Message-State: AOAM531fxhLdFxGBbTq4T5QFYR9xT/oyu4AeX32b/62rwwaJg7KKAuZZ GP8fIR4zmfrF9REdAe8XrtXBF1FWOUFJGyNpWvE= X-Google-Smtp-Source: ABdhPJzYzUKNxjubP/HoBUV/4OIggWcK/l6T8O2Hy0EkcMkvpr2yFaaz2Jjz7sXREOvm1mrrIWImAA== X-Received: by 2002:a19:2d59:: with SMTP id t25mr5811854lft.480.1605778616220; Thu, 19 Nov 2020 01:36:56 -0800 (PST) Received: from [10.0.0.173] (h-155-4-221-184.NA.cust.bahnhof.se. [155.4.221.184]) by smtp.gmail.com with ESMTPSA id 139sm3648033ljj.106.2020.11.19.01.36.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Nov 2020 01:36:55 -0800 (PST) To: txauth@ietf.org References: From: Leif Johansson Autocrypt: addr=leifj@sunet.se; prefer-encrypt=mutual; keydata= mQENBFJK9qIBCACypED81H1N4YmhMJrb4uOtTDzo+lFZDVVOcK11+NhTFl+AZZFnWH/7UPn+ q5ZZBd/IhONfb5QGw5FzTyBWHsbAteXgCvHAIyumwhQzhZnow6myyC6/MwDhomT5rb3MkCKC yQMNfj/yMgL6ZRsXVhlGOLMmOekRfKe2wiC5BhRaQQwPZPwgFS5D0Tro8Xfxjk98u8rNpQXi 9walRAffRY+byhkPiBj0sVA2RXK9Dx2DL3EY0xx07r6Qhs2XkbXNDDCHRuChhHSHwWC16VS9 x7Nhfg2EwKqmMGRNREikjwzDl/aHKz+FXTLONdmc83sRyklqgH90f3na6s/RT5XTb08xABEB AAG0H0xlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZT6JAT4EEwEIACgCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheABQJbtiDqBQkPDsTFAAoJENc61kMK1HjWF/8H/3JZj9Ruv9FI yrntpyCGRDv889XG+cYsUDbl7nZAYbcLUJKq9BfaMzwivPx7M0grYD84squTG/jybh2ONlxb tEANU84JWFCmWWiGnD98JvZmOWqueaOYavef2frN28zLaGh5hPBZnK3PGGCX69hPkoHD76ox NX124d8aZvPpDHuzqGibaJ3/yHPmcC7yTJ/ZKTshQe5LhHI+ev92SMSQFaJIfVq6BcHK6kNT 7tG9U8WCcdGmZ618r0HApAbgFksvnW/Eafxv0vcwZlwr32K0U2VV6fA6rFpdXjlQpV3BldDD d/eq9iwP7EZ4Jgvv38tVI2blBPfAzULVMIy1d8Y2WVm5AQ0EUkr2ogEIAL6TW0U54NLiAzES BGR+JUscV6bAlZCIZkdiG0OCOHrDqYHwbdZn7+APYIynkOAcVELWxbaIyPeA7Ot/LHN30CZZ uFdhx5HoQWRNzo5Wxohv54cf9mjcMrIHUOr0IDl+OOcRDO2L4opJlhbMHQWS3uqt85LpgzXM yMRTFRTCyXWqKvHkO4HJYsNftQtTsf/GY9WEdRVk7xcRoVXab4gLHxjoH3wox4nRDPxvzCna Du9YSTBLZHoiMXSQytHGfFS/ADoRSJm4WmGG5j+VYIm6wuXWiWA4T4EowRRK0lYSLSz6l3wU vW84t40pshQWujT6hmv1vIAGmQ82MzEpXfq6PV0AEQEAAYkBJQQYAQgADwIbDAUCW7YfnAUJ Dw7DdwAKCRDXOtZDCtR41tJUCACZFLpfHO2JT2lzNTASU6eiWacAhShxJd1+WVkAHEtfUyRn hifSMRskoyk84Ay7txCziCeL8Cmucxp7be1qommvBYITqVNw4SF080pIWF0vh4T5QJ31n1L/ w8IzQaSMMX0UBZysgGbJKIeZl8DApseTf4CEOZjY/M36Y7OBTu3znn461ygjTY8MRckZMJT0 xyVi0w0CWuYyZsxQCktIigWW5jfmeUFUMUPdsO4Jvn01uz1oEn1u73nobThdRxi32xOyeQ+m nNfzaPIJzo56D0d7wXV6nsASixx+VQq7Cf1gX+xuWqrbsY7h38FA+1o3DSIbPUfULVBYoRLi 2ThtlFYU Message-ID: <4024dc0d-1950-6adf-cd4e-b5299d516fcb@sunet.se> Date: Thu, 19 Nov 2020 10:36:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 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: [GNAP] security concerns / issues with data in URLs 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, 19 Nov 2020 09:37:03 -0000 On 2020-11-19 02:04, Dick Hardt wrote: > Got it, thanks! > > As we know, there is no certainty of who the originator of a redirect was, and there is no assurance about the integrity or secrecy of the URL contents. With my hat off, I heard Aaron say that it helps to keep state out of URLs because it reduces the risk that state winds up in logs. Its a practical considaration that imo shouldn't be dismissed out of hand. Cheers Leif From nobody Thu Nov 19 05:12: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 BDDBA3A0E51 for ; Thu, 19 Nov 2020 05:12:34 -0800 (PST) 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=agilicus.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 wGhKT5XnMtvk for ; Thu, 19 Nov 2020 05:12:33 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 458283A0E4F for ; Thu, 19 Nov 2020 05:12:32 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id q1so5294855ilt.6 for ; Thu, 19 Nov 2020 05:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agilicus.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YK93bbzR2De3SaXv1PvcfZAoMdPDWjk5kg1XVEHp9SQ=; b=E/TwbNWbrQ5BFmlD1+XcFbRArmxbvv1Rbpe/VfM+UW6dpT43eIsDhZTPeEWYMbbYYO TC0hR7UFq15hcrWmTzPX5w7epUnnt1QC8Iczo93/m8xojBXq6L/YzFMoKSAAGf5BJzQY 8x8/kZ1C5xShJ/gB4I6PMGCfdd/QncEwFbi40eCnozvbR7An1XccGqZN1dhVK4I0Eqj/ VQbtWGvSXhTde0CrKnXarnS9Ncj5NYtiBWiywcqzPBpBFERpgi7FCNeJ52N6CLhWmrXz 78LwyO+NLnsYwHd1/BLzx3djjrfuSnojH/YbfkaPcF1J0HwjTZ+OEva3ePOK0MfJYffQ WZGw== 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=YK93bbzR2De3SaXv1PvcfZAoMdPDWjk5kg1XVEHp9SQ=; b=kAGh2G5lzVZLanPJXP8owpey9G7S3FPhWSl4xgIlgaeB+Gi5R9lnN55czz2fJFlYEJ wVylqk824ybhf7RdQPWF8XMbQFB5ToPRzduiMaL7juCrbLO/hBE+Ekuhri+6mBA4OZAb bWx/b5vKrh3GNmxepfxagYUtCIa2mXpwuT8Hu/kteeal39MbX9D5Xvi9DfD4bSZ0rijg gIeGFy9nQHWiunZtWMPrnrb2CpcNSNSR2VX0eGELivWRmNXvpHQL6CDgBbJGZ//PRToh vjY6CsjpZEz0H1p5IZXkI6K5w4MLWrweZ3rtHlVzrlf2bs65Fo5AHLpe9CP7dB3vY83G pWTg== X-Gm-Message-State: AOAM530D5ZQDgImtXLvb2e35JcvlC6uTmYwHu6mapAbmp84IylPQ91fh U5ED4DM9PgZf4LPqXgDIz2cjm7xCUZOP1b1Y33Z0 X-Google-Smtp-Source: ABdhPJzasAeQ1fwMwc07UDvH/eyNDFNA+eUkVHnzg43US5ANmfoDzrQawezDF5ZTkCNb1qANNOufqDcGOYuKqSQZGR8= X-Received: by 2002:a92:c7ae:: with SMTP id f14mr5448519ilk.202.1605791551828; Thu, 19 Nov 2020 05:12:31 -0800 (PST) MIME-Version: 1.0 References: <4024dc0d-1950-6adf-cd4e-b5299d516fcb@sunet.se> In-Reply-To: <4024dc0d-1950-6adf-cd4e-b5299d516fcb@sunet.se> From: Kyle Larose Date: Thu, 19 Nov 2020 08:12:21 -0500 Message-ID: To: Leif Johansson Cc: txauth@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 19 Nov 2020 13:12:35 -0000 On Thu, 19 Nov 2020 at 04:37, Leif Johansson wrote: > > With my hat off, I heard Aaron say that it helps to keep state out of URLs because > it reduces the risk that state winds up in logs. Its a practical considaration that > imo shouldn't be dismissed out of hand. As an example of where this is likely to happen, many cloud-based implementations of HTTP services use reverse proxies for load balancing amongst other things. These often log requests without understanding the request's intention. From nobody Thu Nov 19 06: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 6AA493A09EA for ; Thu, 19 Nov 2020 06:55:31 -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_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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DUMywbeIE7x for ; Thu, 19 Nov 2020 06:55:29 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 B23123A09F1 for ; Thu, 19 Nov 2020 06:55:29 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id u21so6334774iol.12 for ; Thu, 19 Nov 2020 06:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iUitUInNY53a9VIg6V/NuFYRbFxx91DpbhNEFZZvXq4=; b=iqHcClSctfrXn/m/OYtJ91IHxIaiBKIlBnTkPfTNTzMJXG5DqhgDLlnJfna5HRyKC5 rfXvOSIoMFNLoTaa+T1J0mZgvLHpcGqLp1vVoBVqRfGIOm3DGFQzbQHP//Z6GrIQ20nw OjeTBZYXDeW6c3uYmbH6iNJoXYkum6cwaX/GUuhKLxBsSQxo+K+eNOadDiOjSVryEtA/ Ho2qP1BDpSAgnURo0MPsx4To1V3fy0D/e+2cL/Kmj/foe3XgN7a5Mro4GZ31TNQPMPWe rTgBckStwSg0foUUpoxCMWPCRwlvCQ0asv4DGtJnj2N3RNCe43T96MFEw3Y+weVhveF2 qFuQ== 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=iUitUInNY53a9VIg6V/NuFYRbFxx91DpbhNEFZZvXq4=; b=KSNH+xZg4i8/+exRZlWEfexIu6VtLjG6U5KF0q/Pe3UzCm6c7/jv82nqe+X30UMtpP I484J1JhugY/CALKtJX75Nc8bM8I7v8eyB9cbdEjs3BWOsYVGGejqi5sjiuSven9sX2A eTpYXTNpM8mqfDScVEgrRO3hZZJ1E+qDN1rTHYJ1rtO0E+ytHKNDXrZZ5+ipMUpR6oR6 ZPGMhBJVNR6IELJtkm2ZmNuzTn7zSACx2YgDMd3spSnP1nR8crCLHt1OHhOaDgfgo/aF zfI2n0SwsS8j/e5kRN6KhC37VrevR/2cLtBS4U4r9l96LRab8C1pzQncktUwQyP0Llxs V4/g== X-Gm-Message-State: AOAM531705G/00GpeDUfImhkQU3mgkdL9POftMoS7GeM7D9WUFqCiacS QD1ebht4KkpIy1c1vipXzo90hN5us8sSGA== X-Google-Smtp-Source: ABdhPJwW2PD152+cYelwHvYywhHovGK1YvHyr4xmErjp4EMuBPBJeKYONT/aiptbwKIHxYNOBW5AWA== X-Received: by 2002:a5e:aa17:: with SMTP id s23mr21652094ioe.179.1605797728171; Thu, 19 Nov 2020 06:55:28 -0800 (PST) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com. [209.85.166.182]) by smtp.gmail.com with ESMTPSA id o8sm14074358ioo.20.2020.11.19.06.55.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Nov 2020 06:55:27 -0800 (PST) Received: by mail-il1-f182.google.com with SMTP id y9so5619544ilb.0 for ; Thu, 19 Nov 2020 06:55:26 -0800 (PST) X-Received: by 2002:a92:c5d0:: with SMTP id s16mr20008906ilt.17.1605797726655; Thu, 19 Nov 2020 06:55:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Thu, 19 Nov 2020 06:55:16 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000014212d05b476eb6f" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 19 Nov 2020 14:55:31 -0000 --00000000000014212d05b476eb6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You asked specifically what work in the OAuth group I was referring to. While it=E2=80=99s true that those two concerns I pointed out in OAuth are = more specifically about the use of the front channel than the fact that the URL contains data, there are still concerns with putting data in URLs as pointed out already in this thread. The most straightforward issue is that in practice there are often gateways or reverse proxies in front of servers and they may not be aware of what=E2= =80=99s behind them or that they should avoid logging certain things. While it=E2= =80=99s certainly possible to deploy this in a way that *is* secure and properly configure it to avoid logging where possible, or encrypt data in the URL instead of sign it and such, these seem like just additional concerns that we=E2=80=99ll need to spell out in a security considerations section and ar= e additional ways that an implementation may end up with security issues. Since we have the opportunity to recommend the best path for new developments right now, it feels like we should be taking a more secure stance on this and avoid creating situations that we need to explain our way out of while we can. Aaron Parecki On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt wrote: > Got it, thanks! > > As we know, there is no certainty of who the originator of a redirect was= , > and there is no assurance about the integrity or secrecy of the URL > contents. > > Those are not the case in GNAP with the client calling the AS -- so what > is the risk of having information in the URL? > > You had mentioned the information leaking into logs -- but the AS control= s > those logs -- and the logs are a concern, the AS could put an encrypted > token in the URL. > > =E1=90=A7 > > On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki wrote: > >> I was referring to the work being done to reduce the reliance on the >> front channel: >> >> * Dropping the Implicit grant >> * Adding PAR to initiate an OAuth request from a POST request instead of >> GET >> >> --- >> Aaron Parecki >> https://aaronparecki.com >> >> >> On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt wrote: >> >>> Hey Aaron, >>> >>> In the WG meeting you referenced work in the OAuth WG about removing >>> data that is in URLs for security reaasons. Would you elaborate on what= you >>> were referring to? >>> >>> /Dick >>> =E1=90=A7 >>> >> -- --- Aaron Parecki https://aaronparecki.com --00000000000014212d05b476eb6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You asked specifically what work in the OAuth group I was= referring to.=C2=A0

Whi= le it=E2=80=99s true that those two concerns I pointed out in OAuth are mor= e specifically about the use of the front channel than the fact that the UR= L contains data, there are still concerns with putting data in URLs as poin= ted out already in this thread.

The most straightforward issue is that in practice there are ofte= n gateways or reverse proxies in front of servers and they may not be aware= of what=E2=80=99s behind them or that they should avoid logging certain th= ings. While it=E2=80=99s certainly possible to deploy this in a way that *i= s* secure and properly configure it to avoid logging where possible, or enc= rypt data in the URL instead of sign it and such, these seem like just addi= tional concerns that we=E2=80=99ll need to spell out in a security consider= ations section and are additional ways that an implementation may end up wi= th security issues.=C2=A0

Since we have the opportunity to recommend the best path for new developm= ents right now, it feels like we should be taking a more secure stance on t= his and avoid creating situations that we need to explain our way out of wh= ile we can.

Aaron Pareck= i



On Wed, Nov 1= 8, 2020 at 5:05 PM Dick Hardt <d= ick.hardt@gmail.com> wrote:
Got it, thanks!

As we know, there is no certainty of = who the originator=C2=A0of a redirect was, and there is no assurance about = the integrity or secrecy of the URL contents.

Thos= e are not the case in GNAP with the client calling the AS -- so what is the= risk of having information in the URL?

You had me= ntioned the information=C2=A0leaking into logs -- but the AS controls those= logs -- and the=C2=A0logs are a=C2=A0concern, the=C2=A0AS could put an enc= rypted token in the URL.=C2=A0

3D""=E1=90=A7

On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki= <aaron@parecki.c= om> wrote:
I was referrin= g to the work being done to reduce the reliance on the front channel:
<= br>
* Dropping the Implicit grant
* Adding PAR to initi= ate an OAuth request from a POST request instead of GET

On Wed, Nov 18, 2020 at 3:04 PM= Dick Hardt <d= ick.hardt@gmail.com> wrote:
Hey Aaron,

In the WG meeting you referenced work = in the OAuth WG about removing data that is in URLs for security reaasons. = Would you elaborate on what you were referring to?

/Dick
<= img alt=3D"" style=3D"width: 0px; max-height: 0px; overflow: hidden;" src= =3D"https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%= 3D&type=3Dzerocontent&guid=3Db5120c76-264a-4a04-bb04-4bb151185bd1">= =E1=90=A7
--
---
Aaron Par= ecki

--00000000000014212d05b476eb6f-- From nobody Thu Nov 19 07:02: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 1E0053A0AC6 for ; Thu, 19 Nov 2020 07:02:26 -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 Cdu1xhrcQyc4 for ; Thu, 19 Nov 2020 07:02:23 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 D6F6D3A0AFD for ; Thu, 19 Nov 2020 07:01:26 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id z16so5526171otq.6 for ; Thu, 19 Nov 2020 07:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S3fov4ITP/jyj1u/0UUnfBXqqvYNXmO50tYmFn/mC1U=; b=LgOO9tt47wD/w5mnW3DgyugQq+h7f5TaU4O+F+Nugtt1ZL/fbp2u0itReddk69gWnh PG0yt1DXkJrurtmU/FWs5XT0aqnYr355FWDx+vsDuUyRFjy4fSQAF489koxSfQ0QeXuZ llvjURXsNrbI0xdqif1zkTuTZLfRVTgp6SLEME7UrWTZmFarA7dXmZKXVSaSqRVJdC/Z 9BQPoRvios9mMuPn/6Ll6iPZBZkLAnZgZKu3YHlampusKNV8aXgaxtnab0SYzpajt1PA K8GkVO3OhUTlVGMy2cuEMj8avY5vUn1jarShn0S3R5YyvUC6/JtskxvTkYcrInIZelB1 t8fA== 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=S3fov4ITP/jyj1u/0UUnfBXqqvYNXmO50tYmFn/mC1U=; b=fBf6t14xnnTf+TAMaeHGK4/vOrtGF39n5KIEFfvgErbyd9D/pjhgg5w+GzuCxUx3y4 DIIKyJVWKcrRW2H5+p+WNiukPAyb1ezhCYLP3uvmg++M5+h3zIXfyXm4hYYomoUbuQiy Db4UW+GdCotv+Q/DJk/84X3NigoYQiGi9PVXCZXsIRoHQn3sT/Ik0awlApBtj8Ndkf+g 4w2kM+oHjQ1XXaiypPh8OFPKfa9pO1UrvbuRZt1CuqHXnSyopQCTf8LsbgKzQ7k+CrkO 9AN5v7ZjTthIEwA/lXaynhJ/8XkGFrvwFRE0DVv6YeyFb/1aPjNGQ68XgSyeWBAiH69a 5aIw== X-Gm-Message-State: AOAM5338QupSMAXjQQW3tBbxRmn4OHS0x7pTC1O7/AouV5S/D6Hxt2I/ +2VElWMLVvDQJE1WGlg0aRsNuN3uUQ2srp1Hrn8= X-Google-Smtp-Source: ABdhPJx5Hd20MFK+kYVlMMeH4IWFI1B/l4IQ6YVou8s6sg9UiKwuzSjRmw+iVLUZt2tHzYeyA5RKDjf8RKbAGAC4Mgw= X-Received: by 2002:a9d:708e:: with SMTP id l14mr9887781otj.87.1605798084292; Thu, 19 Nov 2020 07:01:24 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Tom Jones Date: Thu, 19 Nov 2020 07:01:12 -0800 Message-ID: To: Fabien Imbault Cc: Justin Richer , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000065351505b4770013" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 19 Nov 2020 15:02:26 -0000 --00000000000065351505b4770013 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable that would certainly work. But my use case of interest is healthcare, and I cannot imagine forcing users to pay to get an identifier for health care. The other major problem is the 80% of the world's population that lives in what you and I consider to be poverty. Peace ..tom On Wed, Nov 18, 2020 at 10:13 PM Fabien Imbault wrote: > Hi Tom, > > My answer is completely speculative. > But I guess it would probably involve the end-user paying to some sort of > service provider (just like one pays for having a VPN). With the same > potential risks (i.e free tiers that serve ads or resell your data, or > limit volumes of connections)? > > Cheers > Fabien > > > Le jeu. 19 nov. 2020 =C3=A0 06:23, Tom Jones a > =C3=A9crit : > >> Actually that's not the hard problem, which is, once the user wanders of= f >> on some path that is not anchored in the browser, how does the path get >> back to the same place in the browser? >> This is "straightforward" when the path from siop to some url in the >> cloud is completely separated from the path between the user and the >> client, but that is not the path usually taken. >> We need some new entity to pull this off. Call it the AS proxy if you >> will. The problem I have with that is who is going to pay the AS proxy? >> If I can figure that payment issue out, I think I can complete the rest >> of the flows. >> >> Peace ..tom >> >> >> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: >> >>> Ultimately, in most situations like these in the real world, the hurdle >>> isn=E2=80=99t technical compatibility so much as it is trust compatibil= ity. The RP >>> (client) needs to have some incentive to trust the assertions and ident= ity >>> information that=E2=80=99s coming from the AS. The same is true for an = RS trusting >>> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to = do that (which SSI >>> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, >>> because it=E2=80=99s a hard question). >>> >>> Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on >>> device=E2=80=9D element. We=E2=80=99ve got the start of it more than OA= uth2/OIDC have by >>> allowing the bootstrap of the process from a starting call: the interac= tion >>> and continuation URIs handed back by the AS don=E2=80=99t need to be th= e same URIs >>> that the client starts with, so just like SIOP the process can start in >>> HTTP and potentially move to other communication channels. A major >>> difference is that we aren=E2=80=99t dependent on the assumption that t= he user will >>> always be in a browser at some stage, and so the whole raft of >>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That sa= id, we=E2=80=99ve >>> got an opportunity to more explicitly open up alternative communication >>> channels here, and that=E2=80=99s something I=E2=80=99d like to see eng= ineered, even if >>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal = as to how that would >>> work over specific protocols, starting with what we=E2=80=99ve got toda= y. >>> >>> =E2=80=94 Justin >>> >>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >>> wrote: >>> >>> Hi Denis, hi Francis, >>> >>> At some point integration with SSI (on the authentication side) will >>> probably occur, including amongst other possibilities SIOP (since they = work >>> with OpenID a part of the work will probably be made easier). >>> >>> That being said, Denis is right. It's not an AS. Technically it's >>> entirely possible to rely on a decentralized wallet (for instance on yo= ur >>> phone) and a centralized AS. I know of a few studies on how to decentra= lize >>> the AS itself (for instance >>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >>> Maybe it exists, but I'm still looking for real scenarios (or even >>> architectures) where an AS is deployed directly on a phone, and under t= he >>> sole authority of the RO, while being compatible with the rest of the >>> world. >>> >>> Cheers, >>> Fabien >>> >>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>> >>>> Hello Francis, >>>> >>>> See two comments in line. >>>> >>>> >>>> B) Current Document >>>> >>>> Roles description shall not hold any assumption on the physical >>>> structure of the party fulfilling the roles. >>>> [FI] not sure what you mean >>>> >>>> [FP] for example, we assume the AS is a server! In most SSI based use >>>> cases, the AS will be running on the user device. See SIOP ( >>>> https://identity.foundation/did-siop/). >>>> >>>> I browsed through the two drafts, i.e. : >>>> >>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>>> model, and representations W3C Working Draft 08 November 2020 >>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working >>>> Group Draft >>>> >>>> At no place within these two documents, it is possible to imagine that >>>> "the AS will be running on the user device". >>>> >>>> From section 3 of the DIF Working Group Draft: >>>> >>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the >>>> SIOP will not return an access token to the RP". >>>> >>>> An Identity Wallet is not an AS. >>>> >>>> >>>> Roles: >>>> -> grant endpoint of the AS: Why is this a post request? This >>>> eliminates the chance of having user device hosted AS (no server). >>>> [FI] what would you propose instead? >>>> Would also be interested to understand better the deployment model whe= n >>>> there is no server. That's something that was discussed several times = but >>>> I'm still missing the underlying architecture and use case. >>>> >>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>> operated on end user device. >>>> >>>> See the above comment. Please, do not confuse an Identity Wallet with >>>> an Authentication Server (AS). >>>> >>>> Denis >>>> >>>> >>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize the >>>> request or the access to a resource? >>>> [FI] yes, we should make the wording clearer >>>> >>>> Missing Section Interactions: >>>> --> This section shall introduce the notion of interaction before we >>>> start listing interaction types. >>>> [FI] yes >>>> >>>> Interaction Types: >>>> --> I prefer a classification with Redirect, Decoupled and Embedded is= . >>>> In the draft, we have one redirect and 2 decouple interactions and not= hing >>>> else. >>>> [FI] this should be handled as a specific discussion item. As a >>>> reminder, how would you define embedded? >>>> >>>> In practice there's at least these modes: >>>> - redirect and redirect back >>>> - redirect to different browser or device >>>> - user code >>>> - CIBA >>>> >>>> [FP] This classification is limited. >>>> >>>> - Redirect: same device, same or different user agents (browser, >>>> mobile app, desktop app, ...) >>>> - Decoupled: different devices >>>> - Embedded : RC carries RO authorization to AS >>>> >>>> >>>> >>>> Resource Access Request vs. Resource Request >>>> --> Both are mixed up. No clarification of the context of each section= . >>>> [FI] could you clarify what you'd expect. Btw on this topic, there's = a >>>> more general discussion on whether we should make a distinction or not= . >>>> >>>> =E2=80=8B[FP]: Here: >>>> >>>> - Resource Access Request: Requesting Access to a resource. >>>> Response is an access token (or any type of grant) >>>> - Resource Request: Request the resource. Response is the resource >>>> (or a corresponding execution) >>>> >>>> >>>> Token Content Negotiation >>>> --> Not expressed as such. This is central to GNAP and not represented >>>> enough in the document. >>>> [FI] right. This should be a specific discussion item. >>>> >>>> Requesting "User" Information >>>> we identify two types of users: RQ and RO. It will be better not to >>>> refer to a user in this draft, but either to a RQ or an RO. >>>> [FI] yes that would avoid potential misunderstandings. Although in the >>>> end, people will translate RQ into user or end-user most of the time. = Cf in >>>> definition, currently we have Requesting Party (RQ, aka "user") >>>> >>>> >>>> Interaction Again >>>> -> For each interaction type, we will have to describe the protocol >>>> flow and the nature and behavior of involved Roles (Parties), Elements= , >>>> Requests. >>>> [FI] yes >>>> >>>> >>>> [FP] Will these and into tickets? >>>> >>>> Best regards. >>>> /Francis >>>> >>>> >>>> >>>> -- >>>> 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 >>> >> --00000000000065351505b4770013 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
that would certainly work. But my use case of interest is = healthcare, and I cannot imagine forcing users to pay to get an identifier= =C2=A0for health care.
The other major problem is the 80% of the world&= #39;s population that lives in what you and I consider to be poverty.
Peace ..tom


On Wed, Nov 18, 2020 at 10:13 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Tom,

My answer is complete= ly speculative.=C2=A0
But I guess it would probably = involve the end-user paying to some sort of service provider (just like one= pays for having a VPN). With the same potential risks (i.e free tiers that= serve ads or resell your data, or limit volumes of connections)?=C2=A0

Cheers
Fabien=C2=A0


Le jeu. 19 nov. 2020 =C3=A0 06:23, Tom Jone= s <thomasclinganjones@gmail.com> = a =C3=A9crit=C2=A0:
Actually that's not the hard problem, which is, on= ce the user wanders off on some path that is not anchored in the browser, h= ow does the path get back to the same place in the browser?
This is &qu= ot;straightforward" when the path from siop to some url in the cloud i= s completely separated from the path between the user and the client, but t= hat is not the path usually taken.
We need some new entity to pul= l this off. Call it the AS proxy if you will. The problem I have with that = is who is going to pay the AS proxy?
If I can figure that payment= issue out, I think I can complete the rest of the flows.

Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <= jricher@mit.edu> wrote:
Ultimately, in most situa= tions like these in the real world, the hurdle isn=E2=80=99t technical comp= atibility so much as it is trust compatibility. The RP (client) needs to ha= ve some incentive to trust the assertions and identity information that=E2= =80=99s coming from the AS. The same is true for an RS trusting tokens from= the AS. The hard question is less =E2=80=9Chow=E2=80=9D to do that (which = SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support thi= s =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it= more than OAuth2/OIDC have by allowing the bootstrap of the process from a= starting call: the interaction and continuation URIs handed back by the AS= don=E2=80=99t need to be the same URIs that the client starts with, so jus= t like SIOP the process can start in HTTP and potentially move to other com= munication channels. A major difference is that we aren=E2=80=99t dependent= on the assumption that the user will always be in a browser at some stage,= and so the whole raft of front-channel messages that SIOP relies on doesn= =E2=80=99t fly. That said, we=E2=80=99ve got an opportunity to more explici= tly open up alternative communication channels here, and that=E2=80=99s som= ething I=E2=80=99d like to see engineered, even if it=E2=80=99s an extensio= n. I=E2=80=99d love to see a concrete proposal as to how that would work ov= er specific protocols, starting with what we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Denis, hi Francis,=C2=A0

At s= ome point integration with SSI (on the authentication side) will probably o= ccur, including amongst other possibilities SIOP (since they work with Open= ID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically i= t's entirely possible to rely on a decentralized wallet (for instance o= n your phone) and a centralized AS. I know of a few studies on how to decen= tralize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-ha= rdjono-oauth-decentralized-02).
Maybe it exists, but I'm = still looking for real scenarios (or even architectures) where an AS is dep= loyed directly on a phone, and under the sole authority of the RO, while be= ing compatible with the rest of the world.=C2=A0

C= heers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
=C2=A0[FP] for example, we assume the AS is a server! In mo= st SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/di= d-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagi= ne that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP"= .

An Identity Wallet is not an AS.


Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
=C2=A0[FP] See above (SIOP). There will be a lot of identit= y wallets operated on end user device.

See the above comment. Please, do not confuse an Identi= ty Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes=C2= =A0

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code=
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could yo= u clarify what you'd expect.=C2=A0 Btw on this topic, there's a more general discussion on whether we should make a distinction or not.=C2=A0
=E2=80=8B[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a specific discussion item.=C2=A0=

Requesting "User&quo= t; Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user=C2=A0or end-user most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes=C2= =A0=C2=A0

[FP] Will these and into tickets?

Best regards.
/Francis



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

--
TXAuth mailing list
TXAuth@ietf.org
https://www.= ietf.org/mailman/listinfo/txauth
--00000000000065351505b4770013-- From nobody Thu Nov 19 07:17: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 448133A09CC for ; Thu, 19 Nov 2020 07:17:05 -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 74wbE_kfJbKn for ; Thu, 19 Nov 2020 07:17:02 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9ECB3A0B0B for ; Thu, 19 Nov 2020 07:16:43 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id h6so5636828ilj.8 for ; Thu, 19 Nov 2020 07:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Z+8r11ySq41kExNDUuDLAi1d+BIqvY+Y9ne/rkbkao=; b=pT4fpzh2rV+9f7mzQYnzyTtMCXSlB6Q46RIE+/6VQ7bhce1pzWZTbzh2tPs/IWB9t+ Ii9YojMH9NQp3x3zTh4DG75GERneO289jk/lxhCeVYVr6fkoIskZ99ISpRc20rlH0IIG nZ54l2xBN0rEw2H6egjmbDbkfh4Mbmyn8lusKwYjm3uEWHk91o46KR+E/yPQky/eK7ei C5pszP3Cb7f9UtVEgyfNVKnzrJGRaSAVlNpCFPF68+NtACV1b3VUt2aDOQYQT66WemGl +BQ5I5OJKisra1KUcZssKwx3uzU5haM3LKu6+q3hdkJhDvuTp1//+5v8myULPXJ+rhMZ jLFQ== 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=0Z+8r11ySq41kExNDUuDLAi1d+BIqvY+Y9ne/rkbkao=; b=Y5YNvqF/SFFfacO/Yq6q9PNS+kF9HOwLKhEnu1LC30fdxGTBr+3ZQ+cl3Eqy4/1mX+ eK/KMtnVJ3DFeAlZaaqzgibCfw3ggtTgv6ZWlE6LDYM4s/0he+zMHRh8PNiHUUJ5jobh k0NbWIV+ABxtSdMVh0kk4u1eIbxL1Yft98zKB1Jz7AaOUxsBelfBFkQVVg96099IZYDg lWYiUNPLiqNsKKwB4fStSjDFrPOke1g5+1VHfdoxG3gSnUSK2/Y7sYWt0VAOZfrbgoP1 M5z9eTDM/fZqEoAt3UP7nqXmC+qnGtGSXzoUoH8RAz19cjsTedFr9lhsDtFm+eqot1t+ Bl4Q== X-Gm-Message-State: AOAM533TgHgDe7bUr9ft87GEK3+EltxwnujwxZqLRz+dpc6nHH4poaIR 6E9QiY7Q4PTccDFuQ9iFtymOWenSt1CtB49h5jg= X-Google-Smtp-Source: ABdhPJyeJYwFrIAPDCwDW4D0yXIQgsB0D1AKx6hrN+Ago3ek7z4e+sO4eHZVk/uDXvHJPnb9jmUFalmfWFrVbR3UsSY= X-Received: by 2002:a92:9a51:: with SMTP id t78mr6211282ili.178.1605799002872; Thu, 19 Nov 2020 07:16:42 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 19 Nov 2020 16:16:31 +0100 Message-ID: To: Tom Jones Cc: Justin Richer , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000025a24405b477370b" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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, 19 Nov 2020 15:17:05 -0000 --00000000000025a24405b477370b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I suppose trusted institutional actors (hospitals, NGO, etc.) might be willing to support that scenario? Just like in SSI, there's a body of work that is concerned with providing identity to people, https://sovrin.org/identity-for-good-program-helps-provide-ssi-to-ngos-and-= nonprofits/ But unfortunatly many people won't have access to a phone... Cheers Fabien On Thu, Nov 19, 2020 at 4:01 PM Tom Jones wrote: > that would certainly work. But my use case of interest is healthcare, and > I cannot imagine forcing users to pay to get an identifier for health car= e. > The other major problem is the 80% of the world's population that lives i= n > what you and I consider to be poverty. > Peace ..tom > > > On Wed, Nov 18, 2020 at 10:13 PM Fabien Imbault > wrote: > >> Hi Tom, >> >> My answer is completely speculative. >> But I guess it would probably involve the end-user paying to some sort o= f >> service provider (just like one pays for having a VPN). With the same >> potential risks (i.e free tiers that serve ads or resell your data, or >> limit volumes of connections)? >> >> Cheers >> Fabien >> >> >> Le jeu. 19 nov. 2020 =C3=A0 06:23, Tom Jones a >> =C3=A9crit : >> >>> Actually that's not the hard problem, which is, once the user wanders >>> off on some path that is not anchored in the browser, how does the path= get >>> back to the same place in the browser? >>> This is "straightforward" when the path from siop to some url in the >>> cloud is completely separated from the path between the user and the >>> client, but that is not the path usually taken. >>> We need some new entity to pull this off. Call it the AS proxy if you >>> will. The problem I have with that is who is going to pay the AS proxy? >>> If I can figure that payment issue out, I think I can complete the rest >>> of the flows. >>> >>> Peace ..tom >>> >>> >>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: >>> >>>> Ultimately, in most situations like these in the real world, the hurdl= e >>>> isn=E2=80=99t technical compatibility so much as it is trust compatibi= lity. The RP >>>> (client) needs to have some incentive to trust the assertions and iden= tity >>>> information that=E2=80=99s coming from the AS. The same is true for an= RS trusting >>>> tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to= do that (which SSI >>>> answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn= =E2=80=99t answer very well, >>>> because it=E2=80=99s a hard question). >>>> >>>> Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on >>>> device=E2=80=9D element. We=E2=80=99ve got the start of it more than O= Auth2/OIDC have by >>>> allowing the bootstrap of the process from a starting call: the intera= ction >>>> and continuation URIs handed back by the AS don=E2=80=99t need to be t= he same URIs >>>> that the client starts with, so just like SIOP the process can start i= n >>>> HTTP and potentially move to other communication channels. A major >>>> difference is that we aren=E2=80=99t dependent on the assumption that = the user will >>>> always be in a browser at some stage, and so the whole raft of >>>> front-channel messages that SIOP relies on doesn=E2=80=99t fly. That s= aid, we=E2=80=99ve >>>> got an opportunity to more explicitly open up alternative communicatio= n >>>> channels here, and that=E2=80=99s something I=E2=80=99d like to see en= gineered, even if >>>> it=E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal= as to how that would >>>> work over specific protocols, starting with what we=E2=80=99ve got tod= ay. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault >>>> wrote: >>>> >>>> Hi Denis, hi Francis, >>>> >>>> At some point integration with SSI (on the authentication side) will >>>> probably occur, including amongst other possibilities SIOP (since they= work >>>> with OpenID a part of the work will probably be made easier). >>>> >>>> That being said, Denis is right. It's not an AS. Technically it's >>>> entirely possible to rely on a decentralized wallet (for instance on y= our >>>> phone) and a centralized AS. I know of a few studies on how to decentr= alize >>>> the AS itself (for instance >>>> https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). >>>> Maybe it exists, but I'm still looking for real scenarios (or even >>>> architectures) where an AS is deployed directly on a phone, and under = the >>>> sole authority of the RO, while being compatible with the rest of the >>>> world. >>>> >>>> Cheers, >>>> Fabien >>>> >>>> On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: >>>> >>>>> Hello Francis, >>>>> >>>>> See two comments in line. >>>>> >>>>> >>>>> B) Current Document >>>>> >>>>> Roles description shall not hold any assumption on the physical >>>>> structure of the party fulfilling the roles. >>>>> [FI] not sure what you mean >>>>> >>>>> [FP] for example, we assume the AS is a server! In most SSI based us= e >>>>> cases, the AS will be running on the user device. See SIOP ( >>>>> https://identity.foundation/did-siop/). >>>>> >>>>> I browsed through the two drafts, i.e. : >>>>> >>>>> - Decentralized Identifiers (DIDs) v1.0 Core architecture, data >>>>> model, and representations W3C Working Draft 08 November 2020 >>>>> - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF >>>>> Working Group Draft >>>>> >>>>> At no place within these two documents, it is possible to imagine tha= t >>>>> "the AS will be running on the user device". >>>>> >>>>> From section 3 of the DIF Working Group Draft: >>>>> >>>>> "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], th= e >>>>> SIOP will not return an access token to the RP". >>>>> >>>>> An Identity Wallet is not an AS. >>>>> >>>>> >>>>> Roles: >>>>> -> grant endpoint of the AS: Why is this a post request? This >>>>> eliminates the chance of having user device hosted AS (no server). >>>>> [FI] what would you propose instead? >>>>> Would also be interested to understand better the deployment model >>>>> when there is no server. That's something that was discussed several = times >>>>> but I'm still missing the underlying architecture and use case. >>>>> >>>>> [FP] See above (SIOP). There will be a lot of identity wallets >>>>> operated on end user device. >>>>> >>>>> See the above comment. Please, do not confuse an Identity Wallet with >>>>> an Authentication Server (AS). >>>>> >>>>> Denis >>>>> >>>>> >>>>> -> Resource Owner (RO) : Authorizes the request? Does it authorize th= e >>>>> request or the access to a resource? >>>>> [FI] yes, we should make the wording clearer >>>>> >>>>> Missing Section Interactions: >>>>> --> This section shall introduce the notion of interaction before we >>>>> start listing interaction types. >>>>> [FI] yes >>>>> >>>>> Interaction Types: >>>>> --> I prefer a classification with Redirect, Decoupled and Embedded >>>>> is. In the draft, we have one redirect and 2 decouple interactions an= d >>>>> nothing else. >>>>> [FI] this should be handled as a specific discussion item. As a >>>>> reminder, how would you define embedded? >>>>> >>>>> In practice there's at least these modes: >>>>> - redirect and redirect back >>>>> - redirect to different browser or device >>>>> - user code >>>>> - CIBA >>>>> >>>>> [FP] This classification is limited. >>>>> >>>>> - Redirect: same device, same or different user agents (browser, >>>>> mobile app, desktop app, ...) >>>>> - Decoupled: different devices >>>>> - Embedded : RC carries RO authorization to AS >>>>> >>>>> >>>>> >>>>> Resource Access Request vs. Resource Request >>>>> --> Both are mixed up. No clarification of the context of each sectio= n. >>>>> [FI] could you clarify what you'd expect. Btw on this topic, there's >>>>> a more general discussion on whether we should make a distinction or = not. >>>>> >>>>> =E2=80=8B[FP]: Here: >>>>> >>>>> - Resource Access Request: Requesting Access to a resource. >>>>> Response is an access token (or any type of grant) >>>>> - Resource Request: Request the resource. Response is the resource >>>>> (or a corresponding execution) >>>>> >>>>> >>>>> Token Content Negotiation >>>>> --> Not expressed as such. This is central to GNAP and not represente= d >>>>> enough in the document. >>>>> [FI] right. This should be a specific discussion item. >>>>> >>>>> Requesting "User" Information >>>>> we identify two types of users: RQ and RO. It will be better not to >>>>> refer to a user in this draft, but either to a RQ or an RO. >>>>> [FI] yes that would avoid potential misunderstandings. Although in th= e >>>>> end, people will translate RQ into user or end-user most of the time.= Cf in >>>>> definition, currently we have Requesting Party (RQ, aka "user") >>>>> >>>>> >>>>> Interaction Again >>>>> -> For each interaction type, we will have to describe the protocol >>>>> flow and the nature and behavior of involved Roles (Parties), Element= s, >>>>> Requests. >>>>> [FI] yes >>>>> >>>>> >>>>> [FP] Will these and into tickets? >>>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>> --00000000000025a24405b477370b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I suppose trusted=C2=A0institutional=C2=A0actors (hospital= s, NGO, etc.) might be willing to support that scenario?=C2=A0
Just lik= e in SSI, there's a body of work that is concerned with providing ident= ity to people,=C2=A0https://sovrin.org/identity-for= -good-program-helps-provide-ssi-to-ngos-and-nonprofits/=C2=A0But unfort= unatly many people won't have access to a phone...
CheersFabien

On Thu, Nov 19, 2020 at 4:01 PM Tom Jones <thomasclinganjones@gmail.com> = wrote:
that would certainly work. But my use case of interest is healthca= re, and I cannot imagine forcing users to pay to get an identifier=C2=A0for= health care.
The other major problem is the 80% of the world's pop= ulation that lives in what you and I consider to be poverty.
Peace ..tom


On Wed, Nov 18, 2020 at 10:13 PM Fabien Imbault <fabien.imbault@gmai= l.com> wrote:
Hi Tom,

My answer is completely speculative.=C2=A0
But I gu= ess it would probably involve the end-user paying to some sort of service p= rovider (just like one pays for having a VPN). With the same potential risk= s (i.e free tiers that serve ads or resell your data, or limit volumes of c= onnections)?=C2=A0

Cheer= s
Fabien=C2=A0


Le jeu. 19 nov. 2020 = =C3=A0 06:23, Tom Jones <thomasclinganjo= nes@gmail.com> a =C3=A9crit=C2=A0:
Actually that's not the hard= problem, which is, once the user wanders off on some path that is not anch= ored in the browser, how does the path get back to the same place in the br= owser?
This is "straightforward" when the path from siop to s= ome url in the cloud is completely separated from the path between the user= and the client, but that is not the path usually taken.
We need = some new entity to pull this off. Call it the AS proxy if you will. The pro= blem I have with that is who is going to pay the AS proxy?
If I c= an figure that payment issue out, I think I can complete the rest of the fl= ows.

Peace ..tom


On Tue, Nov 17, 2020 at 9:20= AM Justin Richer <jricher@mit.edu>= wrote:
Ult= imately, in most situations like these in the real world, the hurdle isn=E2= =80=99t technical compatibility so much as it is trust compatibility. The R= P (client) needs to have some incentive to trust the assertions and identit= y information that=E2=80=99s coming from the AS. The same is true for an RS= trusting tokens from the AS. The hard question is less =E2=80=9Chow=E2=80= =9D to do that (which SSI answers), but more =E2=80=9Cwhy=E2=80=9D to do th= at (which SSI doesn=E2=80=99t answer very well, because it=E2=80=99s a hard= question).

Still: it=E2=80=99s definitely a question ab= out how to support this =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99= ve got the start of it more than OAuth2/OIDC have by allowing the bootstrap= of the process from a starting call: the interaction and continuation URIs= handed back by the AS don=E2=80=99t need to be the same URIs that the clie= nt starts with, so just like SIOP the process can start in HTTP and potenti= ally move to other communication channels. A major difference is that we ar= en=E2=80=99t dependent on the assumption that the user will always be in a = browser at some stage, and so the whole raft of front-channel messages that= SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an opport= unity to more explicitly open up alternative communication channels here, a= nd that=E2=80=99s something I=E2=80=99d like to see engineered, even if it= =E2=80=99s an extension. I=E2=80=99d love to see a concrete proposal as to = how that would work over specific protocols, starting with what we=E2=80=99= ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Im= bault <fabien.imbault@gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0
At some point integration with SSI (on the authentication = side) will probably occur, including amongst other possibilities SIOP (sinc= e they work with OpenID a part of the work will probably be made easier).= =C2=A0

Maybe = it exists, but I'm still looking for real scenarios (or even architectu= res) where an AS is deployed directly on a phone, and under the sole author= ity of the RO, while being compatible with the rest of the world.=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at= 5:45 PM Denis <denis.ietf@free.fr&= gt; wrote:
=20 =20 =20
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
=C2=A0[FP] for example, we assume the AS is a server! In mo= st SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/di= d-siop/).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working Group Draft

At no place within these two documents, it is possible to imagi= ne that "the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP"= .

An Identity Wallet is not an AS.


Roles:=C2=A0
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
=C2=A0[FP] See above (SIOP). There will be a lot of identit= y wallets operated on end user device.

See the above comment. Please, do not confuse an Identi= ty Wallet with an Authentication Server (AS).

Denis


-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.
[FI] yes=C2= =A0

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code=
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  • Decoupled: different devices
  • Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could yo= u clarify what you'd expect.=C2=A0 Btw on this topic, there's a more general discussion on whether we should make a distinction or not.=C2=A0
=E2=80=8B[FP]: Here:
  • Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a specific discussion item.=C2=A0=

Requesting "User&quo= t; Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user=C2=A0or end-user most of the time. Cf in definition, currently we have=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.
[FI] yes=C2= =A0=C2=A0

[FP] Will these and into tickets?

Best regards.
/Francis



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

--
TXAuth mailing list
TXAuth@ietf.org
https://www.= ietf.org/mailman/listinfo/txauth
--00000000000025a24405b477370b-- From nobody Thu Nov 19 16: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 4E2DE3A1441 for ; Thu, 19 Nov 2020 16:48:26 -0800 (PST) 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 xIXphaWZUXXq for ; Thu, 19 Nov 2020 16:48:24 -0800 (PST) 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 184A13A1440 for ; Thu, 19 Nov 2020 16:48:24 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id u18so11004373lfd.9 for ; Thu, 19 Nov 2020 16:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cuf9gkVtIK4ffR927OiTZaKcat4JSLsKLB8WRGp2IoE=; b=SNZBzTrCGZbQeErC1XQH0sLOpSc3GYqs8EapE38TGgbNuqfHpV4UTS8wasm1rwhPLk 7V6JHo1Dz5bbFi7Me67Guyzx6cURR+i8KF6gVwYgt1kLVxP19whQj+0Xwv9lAP0EBmVY 4FYHcH1Fq3dAFezPedOcvACwZFYbopPoWqVL5h4GAABTlkuxnpCrNTCGQzfDQhU7TDDO 7Tb/8SVYPVXSSzm96+7n2Gxp9BYFYCkedCsH3n2UCjFNO9UC9HHfsZddXcx2l7wGlnVq +ENC881ZsgVnrn4sRRoSshFS90rzVJ5j9JEaS5Ds6wqcrMVjXEF+XWpMXrgMWfDQ8CQo K3xw== 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=Cuf9gkVtIK4ffR927OiTZaKcat4JSLsKLB8WRGp2IoE=; b=ETrJmEI/PDftHr5NKzFWHn4FtU83x9y5HEJC/83JI0eF+j0UFV0w7INh7Wp85fpzvy Jss5S9CYuHG3qeQmIPyUKOUefeiWUK+PThttraHm4+OwHbeY5ZT8bYKApvDHKF0KG4xR hZG91vb9kLFB/OWP/FU6Ii/BV8ezDBrCAlDud0Nci8WsIo7Q3Q+mUil70BsmK4o86Hhu iWjrK1B6nd6ApGcKbC2W7syyxnjV5NxSG2aYzCDiWT+5qPbKTv4GeVQCv+y99nIHPbVx mXh3gkealyuilmwycvynWHLxF9j3TfHpCVM/c+S1F38P6YM+3RF0TWXVWfjcU6EjZ0OV OGmw== X-Gm-Message-State: AOAM531C4AEG8B78PHeT8O9AUzYeZY7LD6e9VvlI3uImeH0R+e37Wrd0 3PDqpiCB5CDDslQ7ymEe95KsZ19vNjL6o0PaZaGnhGR/wqs= X-Google-Smtp-Source: ABdhPJzVVnFF7k0BSencXQN3NJ3esPjri5168nf/25tHsjSECUrjSzUYlXqZuseXUua8MecNFNNZRlXvkF5Bhkno1Cw= X-Received: by 2002:a19:8417:: with SMTP id g23mr6554718lfd.296.1605833301741; Thu, 19 Nov 2020 16:48:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 19 Nov 2020 16:47:45 -0800 Message-ID: To: Aaron Parecki Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000084d35e05b47f330d" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 20 Nov 2020 00:48:26 -0000 --00000000000084d35e05b47f330d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree we should default to a secure stance and not rely on an implementer to deeply understand all the security considerations. There is a large difference though between the effort in OAuth and having state in a URL in GNAP. In OAuth, an implementation MUST put all the parameters into the redirect. PAR allows an implementation to not have to do that. In GNAP, putting state in an "access token" is an implementation choice. Given the client is authenticating on each subsequent call, the server can maintain state on its side, which I think will be in the vast majority of implementations. wrt. state being in the log -- without the client key, what are the risks that are different from seeing the URLs and methods? =E1=90=A7 On Thu, Nov 19, 2020 at 6:55 AM Aaron Parecki wrote: > You asked specifically what work in the OAuth group I was referring to. > > While it=E2=80=99s true that those two concerns I pointed out in OAuth ar= e more > specifically about the use of the front channel than the fact that the UR= L > contains data, there are still concerns with putting data in URLs as > pointed out already in this thread. > > The most straightforward issue is that in practice there are often > gateways or reverse proxies in front of servers and they may not be aware > of what=E2=80=99s behind them or that they should avoid logging certain t= hings. > While it=E2=80=99s certainly possible to deploy this in a way that *is* s= ecure and > properly configure it to avoid logging where possible, or encrypt data in > the URL instead of sign it and such, these seem like just additional > concerns that we=E2=80=99ll need to spell out in a security consideration= s section > and are additional ways that an implementation may end up with security > issues. > > Since we have the opportunity to recommend the best path for new > developments right now, it feels like we should be taking a more secure > stance on this and avoid creating situations that we need to explain our > way out of while we can. > > Aaron Parecki > > > > On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt wrote: > >> Got it, thanks! >> >> As we know, there is no certainty of who the originator of a redirect >> was, and there is no assurance about the integrity or secrecy of the URL >> contents. >> >> Those are not the case in GNAP with the client calling the AS -- so what >> is the risk of having information in the URL? >> >> You had mentioned the information leaking into logs -- but the AS >> controls those logs -- and the logs are a concern, the AS could put an >> encrypted token in the URL. >> >> =E1=90=A7 >> >> On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki wrote: >> >>> I was referring to the work being done to reduce the reliance on the >>> front channel: >>> >>> * Dropping the Implicit grant >>> * Adding PAR to initiate an OAuth request from a POST request instead o= f >>> GET >>> >>> --- >>> Aaron Parecki >>> https://aaronparecki.com >>> >>> >>> On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt wrote= : >>> >>>> Hey Aaron, >>>> >>>> In the WG meeting you referenced work in the OAuth WG about removing >>>> data that is in URLs for security reaasons. Would you elaborate on wha= t you >>>> were referring to? >>>> >>>> /Dick >>>> =E1=90=A7 >>>> >>> -- > --- > Aaron Parecki > https://aaronparecki.com > > --00000000000084d35e05b47f330d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree we should default to a secure stance and not rely = on an implementer=C2=A0to deeply understand all the security considerations= .

There is a large difference though between the effort = in OAuth and having state in a URL in GNAP.

In OAu= th, an implementation MUST put all the parameters=C2=A0into the redirect. P= AR allows an implementation to not have to do that.

In GNAP, putting state in an "access token" is an implementatio= n choice. Given the client is authenticating on each subsequent call, the s= erver can maintain state on its side, which I think will be in the vast maj= ority of implementations.

wrt. state being in the = log -- without the client key, what are the risks that are different from s= eeing the URLs and methods?



=3D""=E1=90=A7

On Thu, Nov 19, 2020 at 6:55 AM Aaron P= arecki <aaron@parecki.com> w= rote:
You asked specifically what work in the OAuth group I was referri= ng to.=C2=A0

While it=E2= =80=99s true that those two concerns I pointed out in OAuth are more specif= ically about the use of the front channel than the fact that the URL contai= ns data, there are still concerns with putting data in URLs as pointed out = already in this thread.

= The most straightforward issue is that in practice there are often gateways= or reverse proxies in front of servers and they may not be aware of what= =E2=80=99s behind them or that they should avoid logging certain things. Wh= ile it=E2=80=99s certainly possible to deploy this in a way that *is* secur= e and properly configure it to avoid logging where possible, or encrypt dat= a in the URL instead of sign it and such, these seem like just additional c= oncerns that we=E2=80=99ll need to spell out in a security considerations s= ection and are additional ways that an implementation may end up with secur= ity issues.=C2=A0

Since = we have the opportunity to recommend the best path for new developments rig= ht now, it feels like we should be taking a more secure stance on this and = avoid creating situations that we need to explain our way out of while we c= an.

Aaron Parecki
<= div dir=3D"auto">


On Wed, Nov 18, 2020= at 5:05 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Got it, thanks!

<= /div>
As we know, there is no certainty of who the originator=C2=A0of a= redirect was, and there is no assurance about the integrity or secrecy of = the URL contents.

Those are not the case in GNAP w= ith the client calling the AS -- so what is the risk of having information = in the URL?

You had mentioned the information=C2= =A0leaking into logs -- but the AS controls those logs -- and the=C2=A0logs= are a=C2=A0concern, the=C2=A0AS could put an encrypted token in the URL.= =C2=A0

3D""=E1=90=A7

On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki <aaron@parecki.com> wrote:
I was r= eferring to the work being done to reduce the reliance on the front channel= :

* Dropping the Implicit grant
* Adding PAR t= o initiate an OAuth request from a POST request instead of GET
---
Aaron Parecki<= div>https://aaronpar= ecki.com


On Wed, Nov 18, 2020 at = 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Aaron,

In the WG meeting you referenced work in the OAuth WG about removing data= that is in URLs for security reaasons. Would you elaborate on what you wer= e referring to?

/Dick
3D""=E1=90=A7
--
---<= /div>Aaron Parecki

--00000000000084d35e05b47f330d-- From nobody Thu Nov 19 17:20: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 A62443A1483 for ; Thu, 19 Nov 2020 17:20:15 -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, 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=parecki.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 qP88yZcHNVlZ for ; Thu, 19 Nov 2020 17:20:13 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 C9E003A1481 for ; Thu, 19 Nov 2020 17:20:13 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id d17so8261284ion.4 for ; Thu, 19 Nov 2020 17:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MHnuPV7j8cj0WshaSfvftH1YiiowQk3zVjwKFCUXCyg=; b=Cd1cJgr42yfVmhFERca+p+hJpE5bCZxYOt0GgRZMI4yAZNqWYgEyHx8X9s27LhDRUk vJJaPm8HRxnXyIgigfO4u8FvWA9Ao2I4WT6S9Q+omcQbxIxyj0wg7hYz00Ol0vO9eCOq Frr3xkz8b8mD6fHtOIUpDJOkq2koAM0SLIVz0cGmnTeQj3ONgDdSiXe7969RzeP7+XVW GQv5Nc/o6APmU4YA/HMHvLvvw84A3jPNaPGRr62NMOL0IVfTqBI7n32KkMGn8DRktnfk YN6RjwejqvQtXOGF97KcMeE/MfFxMmY9+pb08b2041aH5RjN1qF4fvhk3Ss/YxruqIRe PEqg== 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=MHnuPV7j8cj0WshaSfvftH1YiiowQk3zVjwKFCUXCyg=; b=G3MTUt0bgqDkr6Esc0qNYSf2u2uaTsPIZJNd9BoNNxfiCEUS5iaGOBAGoZmOZqtw3/ H5yLLNgm90iCAjUumc7ImVgJQcwo86RRNAP4uHkHj3pand5hwQAacZ+h0hxRbkFnCTxn 7nbbUnP5rJSsGzpeuPTBmlFeRIN4I5f5qdVU4ixr2l4gpoXKBEookMZh+CNFMcpfqWO5 DHFL3ZBAvbHpiGFZzR+ywKYm92TmERSxeXZGrm/4ijaxoWt306eBLMKeBodj5edTDr4l nDHS+gJ5Rc6e2WctjVySnsnN4oEsEpXLXsOBqmYqtMXY6WGr9kYEjMnDquE4wP/CJgJl MBZQ== X-Gm-Message-State: AOAM530uX1x0QLbNKIuswn5lh3FpBnCZSu5dQWpLK1pScuc7/2lObD9B KvFgTLPEUkN0JqdbOMAiCKNhTK0kIyVRhA== X-Google-Smtp-Source: ABdhPJyPZRLMT1nd5JwEoLyoHOzlNBFHgQHdlzrcbeWT2lx8q485GbiNtLuwK/iloJ8PWY5hOh3jpw== X-Received: by 2002:a02:ce83:: with SMTP id y3mr16720445jaq.31.1605835212118; Thu, 19 Nov 2020 17:20:12 -0800 (PST) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com. [209.85.166.48]) by smtp.gmail.com with ESMTPSA id w18sm743887ilq.32.2020.11.19.17.20.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Nov 2020 17:20:10 -0800 (PST) Received: by mail-io1-f48.google.com with SMTP id i9so8264482ioo.2 for ; Thu, 19 Nov 2020 17:20:10 -0800 (PST) X-Received: by 2002:a05:6638:1212:: with SMTP id n18mr14215486jas.38.1605835210201; Thu, 19 Nov 2020 17:20:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Thu, 19 Nov 2020 17:19:59 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000045a25405b47fa515" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 20 Nov 2020 01:20:16 -0000 --00000000000045a25405b47fa515 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable These statements are in conflict with each other: > I agree we should default to a secure stance and not rely on an implementer to deeply understand all the security considerations. and > In GNAP, putting state in an "access token" is an implementation choice. If we give people the option of doing something a less secure way (putting state into the URL), then we have to explain all the security considerations of doing so. By not giving people the option (requiring the access token be sent in a header) then it's secure by default. The risk is if these URLs start containing state, e.g. a JWT, then the contents of the payload may be visible by parties that were not expected to be able to see them, which may have unintended consequences that are not obvious right now. --- Aaron Parecki https://aaronparecki.com On Thu, Nov 19, 2020 at 4:48 PM Dick Hardt wrote: > I agree we should default to a secure stance and not rely on an > implementer to deeply understand all the security considerations. > > There is a large difference though between the effort in OAuth and having > state in a URL in GNAP. > > In OAuth, an implementation MUST put all the parameters into the redirect= . > PAR allows an implementation to not have to do that. > > In GNAP, putting state in an "access token" is an implementation choice. > Given the client is authenticating on each subsequent call, the server ca= n > maintain state on its side, which I think will be in the vast majority of > implementations. > > wrt. state being in the log -- without the client key, what are the risks > that are different from seeing the URLs and methods? > > > > =E1=90=A7 > > On Thu, Nov 19, 2020 at 6:55 AM Aaron Parecki wrote: > >> You asked specifically what work in the OAuth group I was referring to. >> >> While it=E2=80=99s true that those two concerns I pointed out in OAuth a= re more >> specifically about the use of the front channel than the fact that the U= RL >> contains data, there are still concerns with putting data in URLs as >> pointed out already in this thread. >> >> The most straightforward issue is that in practice there are often >> gateways or reverse proxies in front of servers and they may not be awar= e >> of what=E2=80=99s behind them or that they should avoid logging certain = things. >> While it=E2=80=99s certainly possible to deploy this in a way that *is* = secure and >> properly configure it to avoid logging where possible, or encrypt data i= n >> the URL instead of sign it and such, these seem like just additional >> concerns that we=E2=80=99ll need to spell out in a security consideratio= ns section >> and are additional ways that an implementation may end up with security >> issues. >> >> Since we have the opportunity to recommend the best path for new >> developments right now, it feels like we should be taking a more secure >> stance on this and avoid creating situations that we need to explain our >> way out of while we can. >> >> Aaron Parecki >> >> >> >> On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt wrote: >> >>> Got it, thanks! >>> >>> As we know, there is no certainty of who the originator of a redirect >>> was, and there is no assurance about the integrity or secrecy of the UR= L >>> contents. >>> >>> Those are not the case in GNAP with the client calling the AS -- so wha= t >>> is the risk of having information in the URL? >>> >>> You had mentioned the information leaking into logs -- but the AS >>> controls those logs -- and the logs are a concern, the AS could put an >>> encrypted token in the URL. >>> >>> =E1=90=A7 >>> >>> On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki wrote= : >>> >>>> I was referring to the work being done to reduce the reliance on the >>>> front channel: >>>> >>>> * Dropping the Implicit grant >>>> * Adding PAR to initiate an OAuth request from a POST request instead >>>> of GET >>>> >>>> --- >>>> Aaron Parecki >>>> https://aaronparecki.com >>>> >>>> >>>> On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt >>>> wrote: >>>> >>>>> Hey Aaron, >>>>> >>>>> In the WG meeting you referenced work in the OAuth WG about removing >>>>> data that is in URLs for security reaasons. Would you elaborate on wh= at you >>>>> were referring to? >>>>> >>>>> /Dick >>>>> =E1=90=A7 >>>>> >>>> -- >> --- >> Aaron Parecki >> https://aaronparecki.com >> >> --00000000000045a25405b47fa515 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
These statements are in conflict with each other:

=
> I agree we should default to a secure stance and not rely o= n an implementer=C2=A0to deeply understand all the security considerations.=
and
> In GNAP, putting state in an "access token&quo= t; is an implementation choice.

If we give people = the option of doing something a less secure way (putting state into the URL= ), then we have to explain all the security considerations of doing so. By = not giving people the option (requiring the access token be sent in a heade= r) then it's secure by default.

The risk is if= these URLs start containing state, e.g. a JWT, then the contents of the pa= yload may be visible by parties that were not expected to be able to see th= em, which may have unintended consequences that are not obvious right now.<= /div>


On Thu, Nov 19, 2020= at 4:48 PM Dick Hardt <dick.har= dt@gmail.com> wrote:
I agree we should default to a secure stance a= nd not rely on an implementer=C2=A0to deeply understand all the security co= nsiderations.

There is a large difference though between= the effort in OAuth and having state in a URL in GNAP.

In OAuth, an implementation MUST put all the parameters=C2=A0into the= redirect. PAR allows an implementation to not have to do that.
<= br>
In GNAP, putting state in an "access token" is an i= mplementation choice. Given the client is authenticating on each subsequent= call, the server can maintain state on its side, which I think will be in = the vast majority of implementations.

wrt. state b= eing in the log -- without the client key, what are the risks that are diff= erent from seeing the URLs and methods?


=

3D""=E1=90=A7

On Thu, Nov 19, 2020 at= 6:55 AM Aaron Parecki <aaron@parecki.com> wrote:
You asked specifically what work = in the OAuth group I was referring to.=C2=A0

While it=E2=80=99s true that those two concerns I poin= ted out in OAuth are more specifically about the use of the front channel t= han the fact that the URL contains data, there are still concerns with putt= ing data in URLs as pointed out already in this thread.

The most straightforward issue is that in p= ractice there are often gateways or reverse proxies in front of servers and= they may not be aware of what=E2=80=99s behind them or that they should av= oid logging certain things. While it=E2=80=99s certainly possible to deploy= this in a way that *is* secure and properly configure it to avoid logging = where possible, or encrypt data in the URL instead of sign it and such, the= se seem like just additional concerns that we=E2=80=99ll need to spell out = in a security considerations section and are additional ways that an implem= entation may end up with security issues.=C2=A0

=
Since we have the opportunity to recommend the best= path for new developments right now, it feels like we should be taking a m= ore secure stance on this and avoid creating situations that we need to exp= lain our way out of while we can.

Aaron Parecki

=

On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br>
Got it, thanks!

As we know, there is no certainty of wh= o the originator=C2=A0of a redirect was, and there is no assurance about th= e integrity or secrecy of the URL contents.

Those = are not the case in GNAP with the client calling the AS -- so what is the r= isk of having information in the URL?

You had ment= ioned the information=C2=A0leaking into logs -- but the AS controls those l= ogs -- and the=C2=A0logs are a=C2=A0concern, the=C2=A0AS could put an encry= pted token in the URL.=C2=A0

3D""=E1=90=A7

On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki <= ;aaron@parecki.com> wrote:
I was referring to the work being done to reduce the relianc= e on the front channel:

* Dropping the Implicit grant
* Adding PAR to initiate an OAuth request from a POST request inste= ad of GET


On= Wed, Nov 18, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Aaron,=

In the WG meeting you referenced work in the OAuth = WG about removing data that is in URLs for security reaasons. Would you ela= borate on what you were referring to?

/Dick
<= /div>
3D""=E1=90=A7
--
---<= /div>Aaron Parecki

--00000000000045a25405b47fa515-- From nobody Thu Nov 19 17:24: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 E8D503A14AE for ; Thu, 19 Nov 2020 17:24:42 -0800 (PST) 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 4l046hYHI97I for ; Thu, 19 Nov 2020 17:24:41 -0800 (PST) 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 A941A3A14AB for ; Thu, 19 Nov 2020 17:24:40 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id v20so8339962ljk.8 for ; Thu, 19 Nov 2020 17:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r+S2xhqyJCXjWW1TV4tmoTrDaNjWzkyhDxH9sTLB/NY=; b=Nd5Oy9W8VkhZ/Vwj/OQ/PLn2sHi9d3olDitZWG0231ph2hmsEOp9FkroGd+zHfnLif iXszAL84t1SL4C7hcv1ejYp2C0JTOcUFwEHU+R1+9peD868oWBeNRXNt24XpvVD0KvJb tIXRXt+Mpwt551a6atJqF1gE2eD/wmB9QyLXWTNecAe2n89N/1yiStwY61ADy2vbrsRs K12Wlbot+Jypw7JzyhgVj9T0Rn0enD3euf/Wzc1kDpmifUn3f0DEGDirhWbiqlqgAR21 rZDjmMn61Rp8vlbPw15ODOh0fD5DauNskT8q/RU35NFymkiyKJx/wUQsVxJi57637Vze /mLA== 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=r+S2xhqyJCXjWW1TV4tmoTrDaNjWzkyhDxH9sTLB/NY=; b=PJTGUDaTWUgn7jEiIH1SzRa2CTqtSVsxKbLRRv6XXlbocuO92KauIYVwKp69VrDflw J6CjOvPG/JVPjpEUEx3BbMdTU8/dbmPBuAnCJie5MWVIknYy4I3loRGWR8RxkXt7NfEz cvcXHTlUs+TgErJMfh1SbNuUFXN1dzfL0CLsULxS0M4N1yKvSLcQ2baMj161Gs2uiZuA NmI5/cFBtliLcaZC4KJxG+K0ziXoaP/oRokCDx8+VO33QieYoIE6ZewAkOYprPRcuu0A GpOBu8LUkjnQaOcfgNCGSWkYPTRw0HX+RaXtjvCGw38MYhvgApKYV1CZ1i1ART87pNVY TMrw== X-Gm-Message-State: AOAM5325q5fQKRVQXE4VhRMLG0epC72oB15QTwAEveSZdmzOYxq/uV/0 kxX2N6axCwGWpKMavNoVp2YkhKyiSdKUJ6Yx1oVpsb02LqM= X-Google-Smtp-Source: ABdhPJzL0/5d5BkLuIRbnOWeQtb9D5Z0rQBhYePzHFgr13prU+kDQCMVGRCGXLIo1X0bWwyoN+cJ1KFlUfuXsNkUpjE= X-Received: by 2002:a2e:8050:: with SMTP id p16mr7577181ljg.69.1605835478303; Thu, 19 Nov 2020 17:24:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 19 Nov 2020 17:24:02 -0800 Message-ID: To: Aaron Parecki Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000408a9a05b47fb54c" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 20 Nov 2020 01:24:43 -0000 --000000000000408a9a05b47fb54c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Let me clarify -- putting state in what the client sends back to the AS is an implementation choice. The protocol does not have to require it, or provide it as an option. =E1=90=A7 On Thu, Nov 19, 2020 at 5:20 PM Aaron Parecki wrote: > These statements are in conflict with each other: > > > I agree we should default to a secure stance and not rely on an > implementer to deeply understand all the security considerations. > and > > In GNAP, putting state in an "access token" is an implementation choice= . > > If we give people the option of doing something a less secure way (puttin= g > state into the URL), then we have to explain all the security > considerations of doing so. By not giving people the option (requiring th= e > access token be sent in a header) then it's secure by default. > > The risk is if these URLs start containing state, e.g. a JWT, then the > contents of the payload may be visible by parties that were not expected = to > be able to see them, which may have unintended consequences that are not > obvious right now. > > --- > Aaron Parecki > https://aaronparecki.com > > > On Thu, Nov 19, 2020 at 4:48 PM Dick Hardt wrote: > >> I agree we should default to a secure stance and not rely on an >> implementer to deeply understand all the security considerations. >> >> There is a large difference though between the effort in OAuth and havin= g >> state in a URL in GNAP. >> >> In OAuth, an implementation MUST put all the parameters into the >> redirect. PAR allows an implementation to not have to do that. >> >> In GNAP, putting state in an "access token" is an implementation choice. >> Given the client is authenticating on each subsequent call, the server c= an >> maintain state on its side, which I think will be in the vast majority o= f >> implementations. >> >> wrt. state being in the log -- without the client key, what are the risk= s >> that are different from seeing the URLs and methods? >> >> >> >> =E1=90=A7 >> >> On Thu, Nov 19, 2020 at 6:55 AM Aaron Parecki wrote: >> >>> You asked specifically what work in the OAuth group I was referring to. >>> >>> While it=E2=80=99s true that those two concerns I pointed out in OAuth = are more >>> specifically about the use of the front channel than the fact that the = URL >>> contains data, there are still concerns with putting data in URLs as >>> pointed out already in this thread. >>> >>> The most straightforward issue is that in practice there are often >>> gateways or reverse proxies in front of servers and they may not be awa= re >>> of what=E2=80=99s behind them or that they should avoid logging certain= things. >>> While it=E2=80=99s certainly possible to deploy this in a way that *is*= secure and >>> properly configure it to avoid logging where possible, or encrypt data = in >>> the URL instead of sign it and such, these seem like just additional >>> concerns that we=E2=80=99ll need to spell out in a security considerati= ons section >>> and are additional ways that an implementation may end up with security >>> issues. >>> >>> Since we have the opportunity to recommend the best path for new >>> developments right now, it feels like we should be taking a more secure >>> stance on this and avoid creating situations that we need to explain ou= r >>> way out of while we can. >>> >>> Aaron Parecki >>> >>> >>> >>> On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt wrote= : >>> >>>> Got it, thanks! >>>> >>>> As we know, there is no certainty of who the originator of a redirect >>>> was, and there is no assurance about the integrity or secrecy of the U= RL >>>> contents. >>>> >>>> Those are not the case in GNAP with the client calling the AS -- so >>>> what is the risk of having information in the URL? >>>> >>>> You had mentioned the information leaking into logs -- but the AS >>>> controls those logs -- and the logs are a concern, the AS could put an >>>> encrypted token in the URL. >>>> >>>> =E1=90=A7 >>>> >>>> On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki >>>> wrote: >>>> >>>>> I was referring to the work being done to reduce the reliance on the >>>>> front channel: >>>>> >>>>> * Dropping the Implicit grant >>>>> * Adding PAR to initiate an OAuth request from a POST request instead >>>>> of GET >>>>> >>>>> --- >>>>> Aaron Parecki >>>>> https://aaronparecki.com >>>>> >>>>> >>>>> On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt >>>>> wrote: >>>>> >>>>>> Hey Aaron, >>>>>> >>>>>> In the WG meeting you referenced work in the OAuth WG about removing >>>>>> data that is in URLs for security reaasons. Would you elaborate on w= hat you >>>>>> were referring to? >>>>>> >>>>>> /Dick >>>>>> =E1=90=A7 >>>>>> >>>>> -- >>> --- >>> Aaron Parecki >>> https://aaronparecki.com >>> >>> --000000000000408a9a05b47fb54c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Let me clarify -- putting state in what the client sends b= ack to the AS is an implementation choice. The protocol does not have to re= quire it, or provide it as an option.=C2=A0
3D""=E1=90=A7

On Thu, Nov 19, 2020 at 5:20 PM Aaron Parecki <aaron@parecki.com> wrote:
These statements are in c= onflict with each other:

> I agree we should default = to a secure stance and not rely on an implementer=C2=A0to deeply understand= all the security considerations.
and
> In GNAP, putting s= tate in an "access token" is an implementation choice.
=
If we give people the option of doing something a less secur= e way (putting state into the URL), then we have to explain all the securit= y considerations of doing so. By not giving people the option (requiring th= e access token be sent in a header) then it's secure by default.
<= div>
The risk is if these URLs start containing state, e.g. a= JWT, then the contents of the payload may be visible by parties that were = not expected to be able to see them, which may have unintended consequences= that are not obvious right now.

=
---
Aaron Parecki


On Thu, Nov 19, 2020 at 4:48 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:
I agree we should default to a secure stance and not rel= y on an implementer=C2=A0to deeply understand all the security consideratio= ns.

There is a large difference though between the effor= t in OAuth and having state in a URL in GNAP.

In O= Auth, an implementation MUST put all the parameters=C2=A0into the redirect.= PAR allows an implementation to not have to do that.

<= div>In GNAP, putting state in an "access token" is an implementat= ion choice. Given the client is authenticating on each subsequent call, the= server can maintain state on its side, which I think will be in the vast m= ajority of implementations.

wrt. state being in th= e log -- without the client key, what are the risks that are different from= seeing the URLs and methods?



<= /div>
=3D""=E1=90=A7

On Thu, Nov 19, 2020 at 6:55 AM A= aron Parecki <aar= on@parecki.com> wrote:
You asked specifically what work in the OAu= th group I was referring to.=C2=A0

While it=E2=80=99s true that those two concerns I pointed out in= OAuth are more specifically about the use of the front channel than the fa= ct that the URL contains data, there are still concerns with putting data i= n URLs as pointed out already in this thread.

The most straightforward issue is that in practice th= ere are often gateways or reverse proxies in front of servers and they may = not be aware of what=E2=80=99s behind them or that they should avoid loggin= g certain things. While it=E2=80=99s certainly possible to deploy this in a= way that *is* secure and properly configure it to avoid logging where poss= ible, or encrypt data in the URL instead of sign it and such, these seem li= ke just additional concerns that we=E2=80=99ll need to spell out in a secur= ity considerations section and are additional ways that an implementation m= ay end up with security issues.=C2=A0

Since we have the opportunity to recommend the best path for = new developments right now, it feels like we should be taking a more secure= stance on this and avoid creating situations that we need to explain our w= ay out of while we can.

= Aaron Parecki


=

O= n Wed, Nov 18, 2020 at 5:05 PM Dick Hardt <dick.hardt@gmail.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">
Got it, t= hanks!

As we know, there is no certainty of who the orig= inator=C2=A0of a redirect was, and there is no assurance about the integrit= y or secrecy of the URL contents.

Those are not th= e case in GNAP with the client calling the AS -- so what is the risk of hav= ing information in the URL?

You had mentioned the = information=C2=A0leaking into logs -- but the AS controls those logs -- and= the=C2=A0logs are a=C2=A0concern, the=C2=A0AS could put an encrypted token= in the URL.=C2=A0

3D""= =E1=90=A7

On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki <aaron@parecki.com> w= rote:
I was referring to the work being done to reduce the reliance on t= he front channel:

* Dropping the Implicit grant
* Adding PAR to initiate an OAuth request from a POST request instead of = GET

On Wed, = Nov 18, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Aaron,

In the WG meeting you referenced work in the OAuth WG abo= ut removing data that is in URLs for security reaasons. Would you elaborate= on what you were referring to?

/Dick
<= div hspace=3D"streak-pt-mark" style=3D"max-height:1px">3D""=E1=90=A7
--
---<= /div>Aaron Parecki

--000000000000408a9a05b47fb54c-- From nobody Thu Nov 19 18:29: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 D24A53A167E for ; Thu, 19 Nov 2020 18:29:09 -0800 (PST) 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 r7aX4VZvY8sL for ; Thu, 19 Nov 2020 18:29:07 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 CBEBE3A167C for ; Thu, 19 Nov 2020 18:29:07 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id l22so1036852iom.0 for ; Thu, 19 Nov 2020 18:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O0JU/6UJ6Owzc+t29/TKp4y6+4pSrAWUblgNWbaH9xY=; b=II1BOuvlsTRuh4yfdW5RtFBpYJXOhpnRg0dIkj8qXozbHCWV3wB28YnXOrHzTDVvq2 FiMHrP7U53/OPwQ4dLUu1RJLx/bJyhtoZOushFBY6qARd09lnedE63657C/U4tRGc9OC ohM1M+oYpfBcOM9+2WE44PqIz/xj9Lg1axgdLymqQZnk2Q42oUpcgJ6rwoTIp7UQ1Sr0 pd/RgRln9kE8r4G1AGJsmq12VlKudSik+ReI3opeYXX6vntM28S+Tt/a9/vPAk10IxOY jfqNhGZatSoIsunuHC15hrl2FMd19YCuZN7syRpybHgx8d5mlakugNMcGAclVZ04A/dQ b4aA== 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=O0JU/6UJ6Owzc+t29/TKp4y6+4pSrAWUblgNWbaH9xY=; b=irjhJCub7yZl/BicK8ngyn2tl+Y3mU4GFfNsCSZxzjfSg+m9Llk/KJICYtgxZ+d3en D9n17rqVgDo1RKKgLp3geyFi5z7mz1USQH45O5qJ48auPVVSfr2Sp3iENg91Oc1MrcTG DVMwWv7I9aWfRKBRwYsWTH/loofsNjG7YLoB9kWBDuMrNOwWSIv/kmuqz1SN1r3y1EZ0 ZCLsVn1yDu5MG6jDJsr9qC0EavXpcYwIx1i8kfaTq3FufbypScouCUsHLr9eG4TzCzat DEJpppCkmgWmlevP0F2wbg1/OF6rwcM05CzOUAR9eLsfYzB61NkUBEtgrBsOj845nKBW t20w== X-Gm-Message-State: AOAM530AkdT6HfRq6H2q1jp9dmVmLIUqTQBUm6WNYpUoXtocvml7blmk QYeCrgm/IZq7X8j1dYTMIB9CNmYfqG0Wq52Ebfg= X-Google-Smtp-Source: ABdhPJwTdY2AAHosS52HK0yOhUwpHFgDJIrN2JJPAiyMwhH46HzGPaYRybfaLR+Gdld9ueHGC7K8ICnUfv+moLX4FM0= X-Received: by 2002:a6b:4401:: with SMTP id r1mr23034834ioa.78.1605839346934; Thu, 19 Nov 2020 18:29:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Fri, 20 Nov 2020 03:28:54 +0100 Message-ID: To: Dick Hardt Cc: Aaron Parecki , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000d7279505b4809b11" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 20 Nov 2020 02:29:10 -0000 --000000000000d7279505b4809b11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dick, A requirement (must) brings the nice property that it gives no ambiguity in the protocol. Having 2 ways of doing things here will hurt more than it solves anything. Or is there another linked issue you'd like to address (http headers?) before we can close this one? Thanks Fabien Le ven. 20 nov. 2020 =C3=A0 02:24, Dick Hardt a =C3= =A9crit : > Let me clarify -- putting state in what the client sends back to the AS i= s > an implementation choice. The protocol does not have to require it, or > provide it as an option. > =E1=90=A7 > > On Thu, Nov 19, 2020 at 5:20 PM Aaron Parecki wrote: > >> These statements are in conflict with each other: >> >> > I agree we should default to a secure stance and not rely on an >> implementer to deeply understand all the security considerations. >> and >> > In GNAP, putting state in an "access token" is an implementation choic= e. >> >> If we give people the option of doing something a less secure way >> (putting state into the URL), then we have to explain all the security >> considerations of doing so. By not giving people the option (requiring t= he >> access token be sent in a header) then it's secure by default. >> >> The risk is if these URLs start containing state, e.g. a JWT, then the >> contents of the payload may be visible by parties that were not expected= to >> be able to see them, which may have unintended consequences that are not >> obvious right now. >> >> --- >> Aaron Parecki >> https://aaronparecki.com >> >> >> On Thu, Nov 19, 2020 at 4:48 PM Dick Hardt wrote: >> >>> I agree we should default to a secure stance and not rely on an >>> implementer to deeply understand all the security considerations. >>> >>> There is a large difference though between the effort in OAuth and >>> having state in a URL in GNAP. >>> >>> In OAuth, an implementation MUST put all the parameters into the >>> redirect. PAR allows an implementation to not have to do that. >>> >>> In GNAP, putting state in an "access token" is an implementation choice= . >>> Given the client is authenticating on each subsequent call, the server = can >>> maintain state on its side, which I think will be in the vast majority = of >>> implementations. >>> >>> wrt. state being in the log -- without the client key, what are the >>> risks that are different from seeing the URLs and methods? >>> >>> >>> >>> =E1=90=A7 >>> >>> On Thu, Nov 19, 2020 at 6:55 AM Aaron Parecki wrote= : >>> >>>> You asked specifically what work in the OAuth group I was referring to= . >>>> >>>> While it=E2=80=99s true that those two concerns I pointed out in OAuth= are more >>>> specifically about the use of the front channel than the fact that the= URL >>>> contains data, there are still concerns with putting data in URLs as >>>> pointed out already in this thread. >>>> >>>> The most straightforward issue is that in practice there are often >>>> gateways or reverse proxies in front of servers and they may not be aw= are >>>> of what=E2=80=99s behind them or that they should avoid logging certai= n things. >>>> While it=E2=80=99s certainly possible to deploy this in a way that *is= * secure and >>>> properly configure it to avoid logging where possible, or encrypt data= in >>>> the URL instead of sign it and such, these seem like just additional >>>> concerns that we=E2=80=99ll need to spell out in a security considerat= ions section >>>> and are additional ways that an implementation may end up with securit= y >>>> issues. >>>> >>>> Since we have the opportunity to recommend the best path for new >>>> developments right now, it feels like we should be taking a more secur= e >>>> stance on this and avoid creating situations that we need to explain o= ur >>>> way out of while we can. >>>> >>>> Aaron Parecki >>>> >>>> >>>> >>>> On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt >>>> wrote: >>>> >>>>> Got it, thanks! >>>>> >>>>> As we know, there is no certainty of who the originator of a redirect >>>>> was, and there is no assurance about the integrity or secrecy of the = URL >>>>> contents. >>>>> >>>>> Those are not the case in GNAP with the client calling the AS -- so >>>>> what is the risk of having information in the URL? >>>>> >>>>> You had mentioned the information leaking into logs -- but the AS >>>>> controls those logs -- and the logs are a concern, the AS could put a= n >>>>> encrypted token in the URL. >>>>> >>>>> =E1=90=A7 >>>>> >>>>> On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki >>>>> wrote: >>>>> >>>>>> I was referring to the work being done to reduce the reliance on the >>>>>> front channel: >>>>>> >>>>>> * Dropping the Implicit grant >>>>>> * Adding PAR to initiate an OAuth request from a POST request instea= d >>>>>> of GET >>>>>> >>>>>> --- >>>>>> Aaron Parecki >>>>>> https://aaronparecki.com >>>>>> >>>>>> >>>>>> On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt >>>>>> wrote: >>>>>> >>>>>>> Hey Aaron, >>>>>>> >>>>>>> In the WG meeting you referenced work in the OAuth WG about removin= g >>>>>>> data that is in URLs for security reaasons. Would you elaborate on = what you >>>>>>> were referring to? >>>>>>> >>>>>>> /Dick >>>>>>> =E1=90=A7 >>>>>>> >>>>>> -- >>>> --- >>>> Aaron Parecki >>>> https://aaronparecki.com >>>> >>>> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d7279505b4809b11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,=C2=A0

A requirement (must) brings the nice property that it gives n= o ambiguity in the protocol. Having 2 ways of doing things here will hurt m= ore than it solves anything.

Or is there another linked issue you'd like to address (http heade= rs?) before we can close this one?=C2=A0

<= div dir=3D"auto">Thanks
Fabien=C2=A0

Le ven. 20 nov. 2020 =C3=A0 02:24, Dick Hardt <dick.= hardt@gmail.com> a =C3=A9crit=C2=A0:
Let me clarify -- putting state in what the clien= t sends back to the AS is an implementation choice. The protocol does not h= ave to require it, or provide it as an option.=C2=A0
3D""= =E1=90=A7

On Thu, Nov 19, 2020 at 5:20 PM Aaron Parecki <aaron@parecki.com> wrote:
These statements are in conflict with = each other:

> I agree we should default to a secure s= tance and not rely on an implementer=C2=A0to deeply understand all the secu= rity considerations.
and
> In GNAP, putting state in an &q= uot;access token" is an implementation choice.

If we give people the option of doing something a less secure way (puttin= g state into the URL), then we have to explain all the security considerati= ons of doing so. By not giving people the option (requiring the access toke= n be sent in a header) then it's secure by default.

The risk is if these URLs start containing state, e.g. a JWT, then th= e contents of the payload may be visible by parties that were not expected = to be able to see them, which may have unintended consequences that are not= obvious right now.

---
Aaron Parecki

On Thu, Nov 19, 2020 at 4:48 PM= Dick Hardt <dick.hardt@gmail.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 agree w= e should default to a secure stance and not rely on an implementer=C2=A0to = deeply understand all the security considerations.

There= is a large difference though between the effort in OAuth and having state = in a URL in GNAP.

In OAuth, an implementation MUST= put all the parameters=C2=A0into the redirect. PAR allows an implementatio= n to not have to do that.

In GNAP, putting state i= n an "access token" is an implementation choice. Given the client= is authenticating on each subsequent call, the server can maintain state o= n its side, which I think will be in the vast majority of implementations.<= /div>

wrt. state being in the log -- without the client = key, what are the risks that are different from seeing the URLs and methods= ?



3D""=E1=90= =A7

On Thu, Nov 19, 2020 at 6:55 AM Aaron Parecki <aaron= @parecki.com> wrote:
You asked specifically what work in the OAuth= group I was referring to.=C2=A0

While it=E2=80=99s true that those two concerns I pointed out in = OAuth are more specifically about the use of the front channel than the fac= t that the URL contains data, there are still concerns with putting data in= URLs as pointed out already in this thread.

The most straightforward issue is that in practice the= re are often gateways or reverse proxies in front of servers and they may n= ot be aware of what=E2=80=99s behind them or that they should avoid logging= certain things. While it=E2=80=99s certainly possible to deploy this in a = way that *is* secure and properly configure it to avoid logging where possi= ble, or encrypt data in the URL instead of sign it and such, these seem lik= e just additional concerns that we=E2=80=99ll need to spell out in a securi= ty considerations section and are additional ways that an implementation ma= y end up with security issues.=C2=A0

Since we have the opportunity to recommend the best path for n= ew developments right now, it feels like we should be taking a more secure = stance on this and avoid creating situations that we need to explain our wa= y out of while we can.

A= aron Parecki


<= div>
On= Wed, Nov 18, 2020 at 5:05 PM Dick Hardt <dick.hardt@gmail.= com> wrote:
Got it, thanks!

As we know, there is= no certainty of who the originator=C2=A0of a redirect was, and there is no= assurance about the integrity or secrecy of the URL contents.
Those are not the case in GNAP with the client calling the AS = -- so what is the risk of having information in the URL?

You had mentioned the information=C2=A0leaking into logs -- but the = AS controls those logs -- and the=C2=A0logs are a=C2=A0concern, the=C2=A0AS= could put an encrypted token in the URL.=C2=A0

<= div hspace=3D"streak-pt-mark" style=3D"max-height:1px">3D""=E1=90=A7

On Wed, Nov 18, 2020 at 3:38 PM Aar= on Parecki <aaron@parecki.com> wrote:
I was referring = to the work being done to reduce the reliance on the front channel:
* Dropping the Implicit grant
* Adding PAR to initiat= e an OAuth request from a POST request instead of GET

<= div>
---
Aaron Parecki


On = Wed, Nov 18, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.c= om> wrote:
Hey Aaron,

In the WG meeting you = referenced work in the OAuth WG about removing data that is in URLs for sec= urity reaasons. Would you elaborate on what you were referring to?

/Dick
3D""=E1=90=A7<= /div>
--
---<= /div>Aaron Parecki
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--000000000000d7279505b4809b11-- From nobody Thu Nov 19 18:59: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 ED4A83A1706 for ; Thu, 19 Nov 2020 18:59:24 -0800 (PST) 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 ML6cYJ_hwuRB for ; Thu, 19 Nov 2020 18:59:22 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22BD3A1705 for ; Thu, 19 Nov 2020 18:59:21 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id a9so11374590lfh.2 for ; Thu, 19 Nov 2020 18:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uZFiqHZygCF+CIVXHzuUb6cJ9GYzEDsjN8swCIxU8d4=; b=aC4VARh5+0iXwYgOLTMyyyJ3H1RNoseak/8Y4mEYwFObjrtSp2Asho4elyQfhM/8HQ 5xYDU/YFqgi/rpe87LDnMeCeLozZct52lt2zOiQcZCMGpJMKKs4geglg+E3DsJ/I0aCf c92qppWpZrK4Pico5Kmm3PQDBX2MqFnXUlHoUyTH/EEaMZ0FkK55FF4UEIXWj2EYGH85 6XSPx/86csvl0+Omohn6fQcHwLA7zxYQV7EHuO9pdk7pCpWecNe06LTkPDUb2SN1qEPb ic5gSE60S4hBUBz4IoWFMronz+zUNnEKBjEMtAQlNLiUVPJUfNqJT9e0ckWbcgRT+N4c FikA== 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=uZFiqHZygCF+CIVXHzuUb6cJ9GYzEDsjN8swCIxU8d4=; b=jb8N8Oj8JI+a0/m7Mv9DireLnpgfTw6n8W5ioAu0AqbgROn5gX4gdcVDSMFxKI31fE QoEIC5ZvBJN4uHYinbhF3so3bRHoCqngnHaPLpofvL0iogv5e6n4N10GIaztngFdg4uZ sto3ttBom651iy/+PLrAurEnJF55fwDbchKDPqFhLs1a5pu6jTTzG3yOIeGUDmbaN5xo q6JhSgnoH2fEuPs2KAl+ezFaljtXIIbX6O7su2BHqy+7L8tcfTuToZNzg8kcaJshIowE +6ZbrcVyTHde7JmkahaALl1dqpeOXwhWhYJjqb9ddJAXA3oVEv3uSG+p72HmmEiDlBgt 8TUg== X-Gm-Message-State: AOAM531aF0oi0wLkUZ0oetn74tPAljpHD8bBgT4zdM9w+okwyBVTX2Pn jLLw97TCkSsUfliOZC9J5s8WBV61fmekvxUxY6ZpYN9Dw9I= X-Google-Smtp-Source: ABdhPJyBlebjGX1BBAJJyUl8IBDIsS/KKX06xBmfR+2pfCgVRsGlgO4LIh7bonQyCDEYMnFBfQiTwgWXwqUDP7BZyK8= X-Received: by 2002:a19:6e4c:: with SMTP id q12mr6606424lfk.162.1605841159657; Thu, 19 Nov 2020 18:59:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 19 Nov 2020 18:58:42 -0800 Message-ID: To: Fabien Imbault Cc: Aaron Parecki , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000e31fca05b481072d" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 20 Nov 2020 02:59:25 -0000 --000000000000e31fca05b481072d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fabien While I agree that a MUST removes ambiguity -- I'm not sure what issue you are referring to that can be closed as I was not referring to any specific issue. I was getting clarity on what the security issues were in having state in the URL. The issue seems to be state information in logs. While the same issue exists with OAuth redirects, which were held up as an example in the GNAP WG meeting, there are many more security issues with the OAuth redirect that do not apply to having state in a GNAP URL. =E1=90=A7 On Thu, Nov 19, 2020 at 6:29 PM Fabien Imbault wrote: > Hi Dick, > > A requirement (must) brings the nice property that it gives no ambiguity > in the protocol. Having 2 ways of doing things here will hurt more than i= t > solves anything. > > Or is there another linked issue you'd like to address (http headers?) > before we can close this one? > > Thanks > Fabien > > Le ven. 20 nov. 2020 =C3=A0 02:24, Dick Hardt a = =C3=A9crit : > >> Let me clarify -- putting state in what the client sends back to the AS >> is an implementation choice. The protocol does not have to require it, o= r >> provide it as an option. >> =E1=90=A7 >> >> On Thu, Nov 19, 2020 at 5:20 PM Aaron Parecki wrote: >> >>> These statements are in conflict with each other: >>> >>> > I agree we should default to a secure stance and not rely on an >>> implementer to deeply understand all the security considerations. >>> and >>> > In GNAP, putting state in an "access token" is an implementation >>> choice. >>> >>> If we give people the option of doing something a less secure way >>> (putting state into the URL), then we have to explain all the security >>> considerations of doing so. By not giving people the option (requiring = the >>> access token be sent in a header) then it's secure by default. >>> >>> The risk is if these URLs start containing state, e.g. a JWT, then the >>> contents of the payload may be visible by parties that were not expecte= d to >>> be able to see them, which may have unintended consequences that are no= t >>> obvious right now. >>> >>> --- >>> Aaron Parecki >>> https://aaronparecki.com >>> >>> >>> On Thu, Nov 19, 2020 at 4:48 PM Dick Hardt wrote= : >>> >>>> I agree we should default to a secure stance and not rely on an >>>> implementer to deeply understand all the security considerations. >>>> >>>> There is a large difference though between the effort in OAuth and >>>> having state in a URL in GNAP. >>>> >>>> In OAuth, an implementation MUST put all the parameters into the >>>> redirect. PAR allows an implementation to not have to do that. >>>> >>>> In GNAP, putting state in an "access token" is an implementation >>>> choice. Given the client is authenticating on each subsequent call, th= e >>>> server can maintain state on its side, which I think will be in the va= st >>>> majority of implementations. >>>> >>>> wrt. state being in the log -- without the client key, what are the >>>> risks that are different from seeing the URLs and methods? >>>> >>>> >>>> >>>> =E1=90=A7 >>>> >>>> On Thu, Nov 19, 2020 at 6:55 AM Aaron Parecki >>>> wrote: >>>> >>>>> You asked specifically what work in the OAuth group I was referring >>>>> to. >>>>> >>>>> While it=E2=80=99s true that those two concerns I pointed out in OAut= h are >>>>> more specifically about the use of the front channel than the fact th= at the >>>>> URL contains data, there are still concerns with putting data in URLs= as >>>>> pointed out already in this thread. >>>>> >>>>> The most straightforward issue is that in practice there are often >>>>> gateways or reverse proxies in front of servers and they may not be a= ware >>>>> of what=E2=80=99s behind them or that they should avoid logging certa= in things. >>>>> While it=E2=80=99s certainly possible to deploy this in a way that *i= s* secure and >>>>> properly configure it to avoid logging where possible, or encrypt dat= a in >>>>> the URL instead of sign it and such, these seem like just additional >>>>> concerns that we=E2=80=99ll need to spell out in a security considera= tions section >>>>> and are additional ways that an implementation may end up with securi= ty >>>>> issues. >>>>> >>>>> Since we have the opportunity to recommend the best path for new >>>>> developments right now, it feels like we should be taking a more secu= re >>>>> stance on this and avoid creating situations that we need to explain = our >>>>> way out of while we can. >>>>> >>>>> Aaron Parecki >>>>> >>>>> >>>>> >>>>> On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt >>>>> wrote: >>>>> >>>>>> Got it, thanks! >>>>>> >>>>>> As we know, there is no certainty of who the originator of a redirec= t >>>>>> was, and there is no assurance about the integrity or secrecy of the= URL >>>>>> contents. >>>>>> >>>>>> Those are not the case in GNAP with the client calling the AS -- so >>>>>> what is the risk of having information in the URL? >>>>>> >>>>>> You had mentioned the information leaking into logs -- but the AS >>>>>> controls those logs -- and the logs are a concern, the AS could put = an >>>>>> encrypted token in the URL. >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki >>>>>> wrote: >>>>>> >>>>>>> I was referring to the work being done to reduce the reliance on th= e >>>>>>> front channel: >>>>>>> >>>>>>> * Dropping the Implicit grant >>>>>>> * Adding PAR to initiate an OAuth request from a POST request >>>>>>> instead of GET >>>>>>> >>>>>>> --- >>>>>>> Aaron Parecki >>>>>>> https://aaronparecki.com >>>>>>> >>>>>>> >>>>>>> On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt >>>>>>> wrote: >>>>>>> >>>>>>>> Hey Aaron, >>>>>>>> >>>>>>>> In the WG meeting you referenced work in the OAuth WG about >>>>>>>> removing data that is in URLs for security reaasons. Would you ela= borate on >>>>>>>> what you were referring to? >>>>>>>> >>>>>>>> /Dick >>>>>>>> =E1=90=A7 >>>>>>>> >>>>>>> -- >>>>> --- >>>>> Aaron Parecki >>>>> https://aaronparecki.com >>>>> >>>>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000e31fca05b481072d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Fabien

While I agree that a MUS= T removes ambiguity -- I'm not sure what issue you are=C2=A0referring t= o that can be closed as I was not referring to any specific issue.

I was getting clarity on what the security issues were in = having state in the URL.=C2=A0

The issue seems to = be state information in logs.

While the same issue= exists with OAuth redirects, which were held up as an example in the GNAP = WG meeting, there are many more security issues with the OAuth redirect tha= t do not apply=C2=A0to having state in a GNAP URL.



3D""=E1=90=A7

On Thu, Nov 19, 20= 20 at 6:29 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Dick,=C2=A0

A requirement (must) brings the nic= e property that it gives no ambiguity in the protocol. Having 2 ways of doi= ng things here will hurt more than it solves anything.

Or is there another linked issue you'd l= ike to address (http headers?) before we can close this one?=C2=A0

Thanks
Fa= bien=C2=A0

Le ven. 20 nov. 2020 =C3=A0 02:24,= Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
Let me = clarify -- putting state in what the client sends back to the AS is an impl= ementation choice. The protocol does not have to require it, or provide it = as an option.=C2=A0
3D""=E1=90=A7

On Thu, Nov 19,= 2020 at 5:20 PM Aaron Parecki <aaron@parecki.com> wrot= e:
These statements are in conflict with each other:

&g= t; I agree we should default to a secure stance and not rely on an implemen= ter=C2=A0to deeply understand all the security considerations.
and
> In GNAP, putting state in an "access token" is an impl= ementation choice.

If we give people the option of= doing something a less secure way (putting state into the URL), then we ha= ve to explain all the security considerations of doing so. By not giving pe= ople the option (requiring the access token be sent in a header) then it= 9;s secure by default.

The risk is if these URLs s= tart containing state, e.g. a JWT, then the contents of the payload may be = visible by parties that were not expected to be able to see them, which may= have unintended consequences that are not obvious right now.
---
Aaron Pareckihttps://aaronparecki.com

<= /div>

On Thu, Nov 19, 2020 at 4:48 PM Dick Hardt <dick= .hardt@gmail.com> wrote:
I agree we should default to a secure stan= ce and not rely on an implementer=C2=A0to deeply understand all the securit= y considerations.

There is a large difference though bet= ween the effort in OAuth and having state in a URL in GNAP.

<= /div>
In OAuth, an implementation MUST put all the parameters=C2=A0into= the redirect. PAR allows an implementation to not have to do that.

In GNAP, putting state in an "access token" is = an implementation choice. Given the client is authenticating on each subseq= uent call, the server can maintain state on its side, which I think will be= in the vast majority of implementations.

wrt. sta= te being in the log -- without the client key, what are the risks that are = different from seeing the URLs and methods?



3D""=E1=90=A7

On Thu, Nov 19, 202= 0 at 6:55 AM Aaron Parecki <aaron@parecki.com> wrote:
You asked specifically what work in the OAuth group I was referring to.=C2= =A0

While it=E2=80=99s t= rue that those two concerns I pointed out in OAuth are more specifically ab= out the use of the front channel than the fact that the URL contains data, = there are still concerns with putting data in URLs as pointed out already i= n this thread.

The most = straightforward issue is that in practice there are often gateways or rever= se proxies in front of servers and they may not be aware of what=E2=80=99s = behind them or that they should avoid logging certain things. While it=E2= =80=99s certainly possible to deploy this in a way that *is* secure and pro= perly configure it to avoid logging where possible, or encrypt data in the = URL instead of sign it and such, these seem like just additional concerns t= hat we=E2=80=99ll need to spell out in a security considerations section an= d are additional ways that an implementation may end up with security issue= s.=C2=A0

Since we have t= he opportunity to recommend the best path for new developments right now, i= t feels like we should be taking a more secure stance on this and avoid cre= ating situations that we need to explain our way out of while we can.
=

Aaron Parecki



On Wed, Nov 18, 2020 at 5:05= PM Dick Hardt <dick.hardt@gmail.com> wrote:
Got it= , thanks!

As we know, there is no certainty of who the o= riginator=C2=A0of a redirect was, and there is no assurance about the integ= rity or secrecy of the URL contents.

Those are not= the case in GNAP with the client calling the AS -- so what is the risk of = having information in the URL?

You had mentioned t= he information=C2=A0leaking into logs -- but the AS controls those logs -- = and the=C2=A0logs are a=C2=A0concern, the=C2=A0AS could put an encrypted to= ken in the URL.=C2=A0

3D""=E1=90=A7

On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki <aaron@parecki.com> wrote:
I was referring to the work being don= e to reduce the reliance on the front channel:

* Droppin= g the Implicit grant
* Adding PAR to initiate an OAuth request fr= om a POST request instead of GET

=

On Wed, Nov 18, 2020 at = 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=
He= y Aaron,

In the WG meeting you referenced work in th= e OAuth WG about removing data that is in URLs for security reaasons. Would= you elaborate on what you were referring to?

/Dic= k
=E1=90=A7
--
---<= /div>Aaron Parecki
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--000000000000e31fca05b481072d-- From nobody Thu Nov 19 19:17: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 DE40C3A172D for ; Thu, 19 Nov 2020 19:17:42 -0800 (PST) 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 muRhleIfGLBF for ; Thu, 19 Nov 2020 19:17:40 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 14EB93A172C for ; Thu, 19 Nov 2020 19:17:40 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id u21so8451851iol.12 for ; Thu, 19 Nov 2020 19:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GBqvRLezh/zkzzpSxkN7WmjgJYRraxpPHRHqKaXvoYQ=; b=rNaP9RUjtrkKbUAsuB+Qs0ss5rj0gXZypoNsWcG4dYY5cXvo/DxNDVd2DOk7+20qkq 7jVB/XTo9Ufpep2XEqir/K14Udd1Cd56XnG4Ar1U+6aw3M2G22zsHxBso/8WY654A6H7 /L3C1+i2rfSZtlKVBpvMsBG6uXL7rkBJ4pX11Jr2i92NzHiAWqpWtWwWikjezkFCyyls oq8vqlq+NahmZccvkz/JoNkWEs+dtjvvBJp2g/A/g1W6fp34Y8Cb8oyfQjGdu2C33NOd TrX9x3j3aQkUH0YxzU6NioCdcNSAGFKWaMKNIwv19t0Sikd9iFKkNhYsIEGODShIRKfQ 4aIA== 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=GBqvRLezh/zkzzpSxkN7WmjgJYRraxpPHRHqKaXvoYQ=; b=XQpsBCbsxtPpg5mkm9NUi31R+omPqLAs0uRgaF+2xl5rjsR1m1KnQN0M8P4tRDL0oN 1k2vywY3IEINQdn5CQltFs/YDXcw3/gtGB1gPMGRJbEz9ogGeO4eV9fY03K6p3FY0o0e oNg3qrn/26AYtFIVYC9TK0b5VRguAG2mQ9VhKnQKVcXhsXyS/uA0eKSl3foq993zoO7s Io5trZREkuuccqgmyUdGEMsSK8xlW3NCA6q++xMjw6/ReiP2Yv7Jaev9cEQfWSllW80d 7RyQDC4IO2kYgb20weDWmuPU7Wgnd4njHSlKhV/CXhuiaNEekgr2lZ+Y9uA4WXQRwxXT fWBw== X-Gm-Message-State: AOAM531UY2YQq0Fvgr/7GeLJ9XcJaymU8eY6rY6srVkmGL8lHfRi9Rdc NCQoOR4g3gcSaq6n0JinQpofkYeAEXS1FuV2D/8= X-Google-Smtp-Source: ABdhPJzfwCJRn6Oxj+17n4WdfsTSrfierExINiKEqA86eXnU/6AzO+/PIicbB5lQZwQlsjcF7j56+6MQbmDHNb+a3A4= X-Received: by 2002:a6b:4401:: with SMTP id r1mr23178873ioa.78.1605842259265; Thu, 19 Nov 2020 19:17:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Fri, 20 Nov 2020 04:17:27 +0100 Message-ID: To: Dick Hardt Cc: Aaron Parecki , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000006dcf2405b4814968" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 20 Nov 2020 03:17:43 -0000 --0000000000006dcf2405b4814968 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was referring to issue 67, discussed during the call (and during which Aaron made the comment you're discussing in the current thread). Fabien Le ven. 20 nov. 2020 =C3=A0 03:59, Dick Hardt a =C3= =A9crit : > Hi Fabien > > While I agree that a MUST removes ambiguity -- I'm not sure what issue yo= u > are referring to that can be closed as I was not referring to any specifi= c > issue. > > I was getting clarity on what the security issues were in having state in > the URL. > > The issue seems to be state information in logs. > > While the same issue exists with OAuth redirects, which were held up as a= n > example in the GNAP WG meeting, there are many more security issues with > the OAuth redirect that do not apply to having state in a GNAP URL. > > > > =E1=90=A7 > > On Thu, Nov 19, 2020 at 6:29 PM Fabien Imbault > wrote: > >> Hi Dick, >> >> A requirement (must) brings the nice property that it gives no ambiguity >> in the protocol. Having 2 ways of doing things here will hurt more than = it >> solves anything. >> >> Or is there another linked issue you'd like to address (http headers?) >> before we can close this one? >> >> Thanks >> Fabien >> >> Le ven. 20 nov. 2020 =C3=A0 02:24, Dick Hardt a = =C3=A9crit : >> >>> Let me clarify -- putting state in what the client sends back to the AS >>> is an implementation choice. The protocol does not have to require it, = or >>> provide it as an option. >>> =E1=90=A7 >>> >>> On Thu, Nov 19, 2020 at 5:20 PM Aaron Parecki wrote= : >>> >>>> These statements are in conflict with each other: >>>> >>>> > I agree we should default to a secure stance and not rely on an >>>> implementer to deeply understand all the security considerations. >>>> and >>>> > In GNAP, putting state in an "access token" is an implementation >>>> choice. >>>> >>>> If we give people the option of doing something a less secure way >>>> (putting state into the URL), then we have to explain all the security >>>> considerations of doing so. By not giving people the option (requiring= the >>>> access token be sent in a header) then it's secure by default. >>>> >>>> The risk is if these URLs start containing state, e.g. a JWT, then the >>>> contents of the payload may be visible by parties that were not expect= ed to >>>> be able to see them, which may have unintended consequences that are n= ot >>>> obvious right now. >>>> >>>> --- >>>> Aaron Parecki >>>> https://aaronparecki.com >>>> >>>> >>>> On Thu, Nov 19, 2020 at 4:48 PM Dick Hardt >>>> wrote: >>>> >>>>> I agree we should default to a secure stance and not rely on an >>>>> implementer to deeply understand all the security considerations. >>>>> >>>>> There is a large difference though between the effort in OAuth and >>>>> having state in a URL in GNAP. >>>>> >>>>> In OAuth, an implementation MUST put all the parameters into the >>>>> redirect. PAR allows an implementation to not have to do that. >>>>> >>>>> In GNAP, putting state in an "access token" is an implementation >>>>> choice. Given the client is authenticating on each subsequent call, t= he >>>>> server can maintain state on its side, which I think will be in the v= ast >>>>> majority of implementations. >>>>> >>>>> wrt. state being in the log -- without the client key, what are the >>>>> risks that are different from seeing the URLs and methods? >>>>> >>>>> >>>>> >>>>> =E1=90=A7 >>>>> >>>>> On Thu, Nov 19, 2020 at 6:55 AM Aaron Parecki >>>>> wrote: >>>>> >>>>>> You asked specifically what work in the OAuth group I was referring >>>>>> to. >>>>>> >>>>>> While it=E2=80=99s true that those two concerns I pointed out in OAu= th are >>>>>> more specifically about the use of the front channel than the fact t= hat the >>>>>> URL contains data, there are still concerns with putting data in URL= s as >>>>>> pointed out already in this thread. >>>>>> >>>>>> The most straightforward issue is that in practice there are often >>>>>> gateways or reverse proxies in front of servers and they may not be = aware >>>>>> of what=E2=80=99s behind them or that they should avoid logging cert= ain things. >>>>>> While it=E2=80=99s certainly possible to deploy this in a way that *= is* secure and >>>>>> properly configure it to avoid logging where possible, or encrypt da= ta in >>>>>> the URL instead of sign it and such, these seem like just additional >>>>>> concerns that we=E2=80=99ll need to spell out in a security consider= ations section >>>>>> and are additional ways that an implementation may end up with secur= ity >>>>>> issues. >>>>>> >>>>>> Since we have the opportunity to recommend the best path for new >>>>>> developments right now, it feels like we should be taking a more sec= ure >>>>>> stance on this and avoid creating situations that we need to explain= our >>>>>> way out of while we can. >>>>>> >>>>>> Aaron Parecki >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt >>>>>> wrote: >>>>>> >>>>>>> Got it, thanks! >>>>>>> >>>>>>> As we know, there is no certainty of who the originator of a >>>>>>> redirect was, and there is no assurance about the integrity or secr= ecy of >>>>>>> the URL contents. >>>>>>> >>>>>>> Those are not the case in GNAP with the client calling the AS -- so >>>>>>> what is the risk of having information in the URL? >>>>>>> >>>>>>> You had mentioned the information leaking into logs -- but the AS >>>>>>> controls those logs -- and the logs are a concern, the AS could put= an >>>>>>> encrypted token in the URL. >>>>>>> >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki >>>>>>> wrote: >>>>>>> >>>>>>>> I was referring to the work being done to reduce the reliance on >>>>>>>> the front channel: >>>>>>>> >>>>>>>> * Dropping the Implicit grant >>>>>>>> * Adding PAR to initiate an OAuth request from a POST request >>>>>>>> instead of GET >>>>>>>> >>>>>>>> --- >>>>>>>> Aaron Parecki >>>>>>>> https://aaronparecki.com >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey Aaron, >>>>>>>>> >>>>>>>>> In the WG meeting you referenced work in the OAuth WG about >>>>>>>>> removing data that is in URLs for security reaasons. Would you el= aborate on >>>>>>>>> what you were referring to? >>>>>>>>> >>>>>>>>> /Dick >>>>>>>>> =E1=90=A7 >>>>>>>>> >>>>>>>> -- >>>>>> --- >>>>>> Aaron Parecki >>>>>> https://aaronparecki.com >>>>>> >>>>>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --0000000000006dcf2405b4814968 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was referring to issue 67, discussed during the call (a= nd during which Aaron made the comment you're discussing in the current= thread).

Fabien=C2=A0

Le= ven. 20 nov. 2020 =C3=A0 03:59, Dick Hardt <dick.hardt@gmail.com&= gt; a =C3=A9crit=C2=A0:
Hi=C2=A0Fabien

While I agree that a MUST removes a= mbiguity -- I'm not sure what issue you are=C2=A0referring to that can = be closed as I was not referring to any specific issue.

I was getting clarity on what the security issues were in having stat= e in the URL.=C2=A0

The issue seems to be state in= formation in logs.

While the same issue exists wit= h OAuth redirects, which were held up as an example in the GNAP WG meeting,= there are many more security issues with the OAuth redirect that do not ap= ply=C2=A0to having state in a GNAP URL.


=

3D""=E1=90=A7

On Thu, Nov 19, 2020 at 6:29 = PM Fabien Imbault <fabien.imbault@gmail.com> wro= te:
Hi Dick,=C2=A0

A requirement (must) brings the nice property that it gives no ambiguity = in the protocol. Having 2 ways of doing things here will hurt more than it = solves anything.

Or is t= here another linked issue you'd like to address (http headers?) before = we can close this one?=C2=A0

Thanks
Fabien=C2=A0

=
Le ven. 20 nov. 2020 =C3=A0 02:24, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
Let me clarify -- putti= ng state in what the client sends back to the AS is an implementation choic= e. The protocol does not have to require it, or provide it as an option.=C2= =A0
=E1=90=A7

On Thu, Nov 19, 2020 at 5:20 PM Aar= on Parecki <aaron@parecki.com> wr= ote:
These statements are in conflict with each other:

= > I agree we should default to a secure stance and not rely on an implem= enter=C2=A0to deeply understand all the security considerations.
and
> In GNAP, putting state in an "access token" is an im= plementation choice.

If we give people the option = of doing something a less secure way (putting state into the URL), then we = have to explain all the security considerations of doing so. By not giving = people the option (requiring the access token be sent in a header) then it&= #39;s secure by default.

The risk is if these URLs= start containing state, e.g. a JWT, then the contents of the payload may b= e visible by parties that were not expected to be able to see them, which m= ay have unintended consequences that are not obvious right now.
<= br>
---
Aaron Parecki=

On Thu, Nov 19, 2020 at 4:48 PM Dick Har= dt <dick.hardt@gmail.com> wrot= e:
I agree we should default to a secure stance and not rely on an impleme= nter=C2=A0to deeply understand all the security considerations.

There is a large difference though between the effort in OAuth and = having state in a URL in GNAP.

In OAuth, an implem= entation MUST put all the parameters=C2=A0into the redirect. PAR allows an = implementation to not have to do that.

In GNAP, pu= tting state in an "access token" is an implementation choice. Giv= en the client is authenticating on each subsequent call, the server can mai= ntain state on its side, which I think will be in the vast majority of impl= ementations.

wrt. state being in the log -- withou= t the client key, what are the risks that are different from seeing the URL= s and methods?



3D""=E1=90=A7

On Thu, Nov 19, 2020 at 6:55 AM Aaron Parecki <aaron@parecki.com> wrote:
You asked = specifically what work in the OAuth group I was referring to.=C2=A0

While it=E2=80=99s true that th= ose two concerns I pointed out in OAuth are more specifically about the use= of the front channel than the fact that the URL contains data, there are s= till concerns with putting data in URLs as pointed out already in this thre= ad.

The most straightfor= ward issue is that in practice there are often gateways or reverse proxies = in front of servers and they may not be aware of what=E2=80=99s behind them= or that they should avoid logging certain things. While it=E2=80=99s certa= inly possible to deploy this in a way that *is* secure and properly configu= re it to avoid logging where possible, or encrypt data in the URL instead o= f sign it and such, these seem like just additional concerns that we=E2=80= =99ll need to spell out in a security considerations section and are additi= onal ways that an implementation may end up with security issues.=C2=A0

Since we have the opportuni= ty to recommend the best path for new developments right now, it feels like= we should be taking a more secure stance on this and avoid creating situat= ions that we need to explain our way out of while we can.

Aaron Parecki

=


On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt= <dick.hardt@gmail.com> wrote:=
Got it, thanks!

As we know, there is no certainty of w= ho the originator=C2=A0of a redirect was, and there is no assurance about t= he integrity or secrecy of the URL contents.

Those= are not the case in GNAP with the client calling the AS -- so what is the = risk of having information in the URL?

You had men= tioned the information=C2=A0leaking into logs -- but the AS controls those = logs -- and the=C2=A0logs are a=C2=A0concern, the=C2=A0AS could put an encr= ypted token in the URL.=C2=A0

3D""=E1=90=A7

On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki <aaron@parecki.com> wrote:
I was refer= ring to the work being done to reduce the reliance on the front channel:
* Dropping the Implicit grant
* Adding PAR to in= itiate an OAuth request from a POST request instead of GET

---
Aaron Parecki

=

On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Aar= on,

In the WG meeting you referenced work in the OAu= th WG about removing data that is in URLs for security reaasons. Would you = elaborate on what you were referring to?

/Dick
3D==E1=90=A7
--
---<= /div>Aaron Parecki

--
TXAuth mailing list
TXAuth@ietf.org
https://www.= ietf.org/mailman/listinfo/txauth
--0000000000006dcf2405b4814968-- From nobody Thu Nov 19 20:00: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 603673A17AB for ; Thu, 19 Nov 2020 20:00:37 -0800 (PST) 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 kebKvjhwGU0T for ; Thu, 19 Nov 2020 20:00:35 -0800 (PST) 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 B06843A17AA for ; Thu, 19 Nov 2020 20:00:34 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id w142so11495060lff.8 for ; Thu, 19 Nov 2020 20:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1lVVWsnnYu9TzeQxs3ajX0JPswhHh8VWWKVcZR6B3eE=; b=q/t8wHHEnjgbTpIhOG4tGgYwNhU2pZp/aE3oUHEpPZQRvAgUWnjIRryFP8AWYgkCJS 8gxkKwOjxTk6dRfy1Ny1k0sHQ7DYA/ByTmg5f889ycY/HaHXEl4mfvNMPjb90tdQX5JG zjWF1t9/NE+v3PYD2o4PIscVwZtKzo7drFHmWIUD0JugYaHECzzVOiMxxUqUVffKUBdG gAD8ieb9yc3lHP8vjex+DGDyXPkLLzCklhK65PqibVkCJoC6lkDmlgFbQyiTX9eD9PwC 9M7Zxchkzzn0m30Xu1EblRPM1UgkqrKDeVd24iKR+VOW6IKICyZMS4kIb04wR6+bvKtb +tUw== 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=1lVVWsnnYu9TzeQxs3ajX0JPswhHh8VWWKVcZR6B3eE=; b=B2Lqvs7NusWK32jw95ZjLjbK41eiflRMyQYmVWIctN03om2JO0csFdqD/8ZeGJOiGf vE5knk111Kp8IZIOfz9PX/3NC04oEloQLlysgA4YdhCxR+SG60rFExt+7m+3OTaDSjtk s6dffbxf3DbSS5NCkl67KD0Lf1YJRbYmOY+M1iVrmBVqqvXZrvLbP89SJBMijubPi2XH nr2SCLWDe60fxVhDleHLFag1cUqhApkueNJRJ660/t6ARXFa44J1h/qv1se9pJSs0FzX uY8yUKXrT/AhHT7JImXkval6I5+TAkEsiBDp8p84AMjAmTk9Oxdb6pJlIcYySDESKP0r 5FKA== X-Gm-Message-State: AOAM533UyBm/5AUyfAk4nX5mBlb8ZIIbtaUCVTXaa3+ACpCacQe+D1Ok C65kf0Qoq58wVDL0A0zstP197l2QYFPqWK3tJp8= X-Google-Smtp-Source: ABdhPJzOSjpNsdJq17l/vWPw/KwXvX1oubikhUa7mV/nqF1MaTXZmk5pz2rjGG4n5SWMNPotQNOG4ZuPiPwkp175bII= X-Received: by 2002:a05:6512:6c5:: with SMTP id u5mr7559875lff.316.1605844832536; Thu, 19 Nov 2020 20:00:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 19 Nov 2020 19:59:56 -0800 Message-ID: To: Fabien Imbault Cc: Aaron Parecki , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000cecdab05b481e2ff" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 20 Nov 2020 04:00:37 -0000 --000000000000cecdab05b481e2ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Got it. I have not yet had time to go over the issues and comment. I did look at 67, and I have a fair amount of feedback on it that I hope to provide soon. =E1=90=A7 On Thu, Nov 19, 2020 at 7:17 PM Fabien Imbault wrote: > I was referring to issue 67, discussed during the call (and during which > Aaron made the comment you're discussing in the current thread). > > Fabien > > Le ven. 20 nov. 2020 =C3=A0 03:59, Dick Hardt a = =C3=A9crit : > >> Hi Fabien >> >> While I agree that a MUST removes ambiguity -- I'm not sure what issue >> you are referring to that can be closed as I was not referring to any >> specific issue. >> >> I was getting clarity on what the security issues were in having state i= n >> the URL. >> >> The issue seems to be state information in logs. >> >> While the same issue exists with OAuth redirects, which were held up as >> an example in the GNAP WG meeting, there are many more security issues w= ith >> the OAuth redirect that do not apply to having state in a GNAP URL. >> >> >> >> =E1=90=A7 >> >> On Thu, Nov 19, 2020 at 6:29 PM Fabien Imbault >> wrote: >> >>> Hi Dick, >>> >>> A requirement (must) brings the nice property that it gives no ambiguit= y >>> in the protocol. Having 2 ways of doing things here will hurt more than= it >>> solves anything. >>> >>> Or is there another linked issue you'd like to address (http headers?) >>> before we can close this one? >>> >>> Thanks >>> Fabien >>> >>> Le ven. 20 nov. 2020 =C3=A0 02:24, Dick Hardt a >>> =C3=A9crit : >>> >>>> Let me clarify -- putting state in what the client sends back to the A= S >>>> is an implementation choice. The protocol does not have to require it,= or >>>> provide it as an option. >>>> =E1=90=A7 >>>> >>>> On Thu, Nov 19, 2020 at 5:20 PM Aaron Parecki >>>> wrote: >>>> >>>>> These statements are in conflict with each other: >>>>> >>>>> > I agree we should default to a secure stance and not rely on an >>>>> implementer to deeply understand all the security considerations. >>>>> and >>>>> > In GNAP, putting state in an "access token" is an implementation >>>>> choice. >>>>> >>>>> If we give people the option of doing something a less secure way >>>>> (putting state into the URL), then we have to explain all the securit= y >>>>> considerations of doing so. By not giving people the option (requirin= g the >>>>> access token be sent in a header) then it's secure by default. >>>>> >>>>> The risk is if these URLs start containing state, e.g. a JWT, then th= e >>>>> contents of the payload may be visible by parties that were not expec= ted to >>>>> be able to see them, which may have unintended consequences that are = not >>>>> obvious right now. >>>>> >>>>> --- >>>>> Aaron Parecki >>>>> https://aaronparecki.com >>>>> >>>>> >>>>> On Thu, Nov 19, 2020 at 4:48 PM Dick Hardt >>>>> wrote: >>>>> >>>>>> I agree we should default to a secure stance and not rely on an >>>>>> implementer to deeply understand all the security considerations. >>>>>> >>>>>> There is a large difference though between the effort in OAuth and >>>>>> having state in a URL in GNAP. >>>>>> >>>>>> In OAuth, an implementation MUST put all the parameters into the >>>>>> redirect. PAR allows an implementation to not have to do that. >>>>>> >>>>>> In GNAP, putting state in an "access token" is an implementation >>>>>> choice. Given the client is authenticating on each subsequent call, = the >>>>>> server can maintain state on its side, which I think will be in the = vast >>>>>> majority of implementations. >>>>>> >>>>>> wrt. state being in the log -- without the client key, what are the >>>>>> risks that are different from seeing the URLs and methods? >>>>>> >>>>>> >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> On Thu, Nov 19, 2020 at 6:55 AM Aaron Parecki >>>>>> wrote: >>>>>> >>>>>>> You asked specifically what work in the OAuth group I was referring >>>>>>> to. >>>>>>> >>>>>>> While it=E2=80=99s true that those two concerns I pointed out in OA= uth are >>>>>>> more specifically about the use of the front channel than the fact = that the >>>>>>> URL contains data, there are still concerns with putting data in UR= Ls as >>>>>>> pointed out already in this thread. >>>>>>> >>>>>>> The most straightforward issue is that in practice there are often >>>>>>> gateways or reverse proxies in front of servers and they may not be= aware >>>>>>> of what=E2=80=99s behind them or that they should avoid logging cer= tain things. >>>>>>> While it=E2=80=99s certainly possible to deploy this in a way that = *is* secure and >>>>>>> properly configure it to avoid logging where possible, or encrypt d= ata in >>>>>>> the URL instead of sign it and such, these seem like just additiona= l >>>>>>> concerns that we=E2=80=99ll need to spell out in a security conside= rations section >>>>>>> and are additional ways that an implementation may end up with secu= rity >>>>>>> issues. >>>>>>> >>>>>>> Since we have the opportunity to recommend the best path for new >>>>>>> developments right now, it feels like we should be taking a more se= cure >>>>>>> stance on this and avoid creating situations that we need to explai= n our >>>>>>> way out of while we can. >>>>>>> >>>>>>> Aaron Parecki >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt >>>>>>> wrote: >>>>>>> >>>>>>>> Got it, thanks! >>>>>>>> >>>>>>>> As we know, there is no certainty of who the originator of a >>>>>>>> redirect was, and there is no assurance about the integrity or sec= recy of >>>>>>>> the URL contents. >>>>>>>> >>>>>>>> Those are not the case in GNAP with the client calling the AS -- s= o >>>>>>>> what is the risk of having information in the URL? >>>>>>>> >>>>>>>> You had mentioned the information leaking into logs -- but the AS >>>>>>>> controls those logs -- and the logs are a concern, the AS could pu= t an >>>>>>>> encrypted token in the URL. >>>>>>>> >>>>>>>> =E1=90=A7 >>>>>>>> >>>>>>>> On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I was referring to the work being done to reduce the reliance on >>>>>>>>> the front channel: >>>>>>>>> >>>>>>>>> * Dropping the Implicit grant >>>>>>>>> * Adding PAR to initiate an OAuth request from a POST request >>>>>>>>> instead of GET >>>>>>>>> >>>>>>>>> --- >>>>>>>>> Aaron Parecki >>>>>>>>> https://aaronparecki.com >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hey Aaron, >>>>>>>>>> >>>>>>>>>> In the WG meeting you referenced work in the OAuth WG about >>>>>>>>>> removing data that is in URLs for security reaasons. Would you e= laborate on >>>>>>>>>> what you were referring to? >>>>>>>>>> >>>>>>>>>> /Dick >>>>>>>>>> =E1=90=A7 >>>>>>>>>> >>>>>>>>> -- >>>>>>> --- >>>>>>> Aaron Parecki >>>>>>> https://aaronparecki.com >>>>>>> >>>>>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --000000000000cecdab05b481e2ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got it.

I have not yet had time to go o= ver the issues and comment. I did look at 67, and I have a fair amount of f= eedback=C2=A0on it that I hope to provide soon.

<= div hspace=3D"streak-pt-mark" style=3D"max-height:1px">3D""=E1=90=A7
On Thu, Nov 19, 2020 at 7:17 PM Fabien Imbault <= ;fabien.imbault@gmail.com&g= t; wrote:
I was referring to issue 67, discussed during the call (and dur= ing which Aaron made the comment you're discussing in the current threa= d).

Fabien=C2=A0
Le ven. = 20 nov. 2020 =C3=A0 03:59, Dick Hardt <dick.hardt@gmail.com> a = =C3=A9crit=C2=A0:
Hi=C2=A0Fabien

While I agree that a M= UST removes ambiguity -- I'm not sure what issue you are=C2=A0referring= to that can be closed as I was not referring to any specific issue.
<= div>
I was getting clarity on what the security issues were i= n having state in the URL.=C2=A0

The issue seems t= o be state information in logs.

While the same iss= ue exists with OAuth redirects, which were held up as an example in the GNA= P WG meeting, there are many more security issues with the OAuth redirect t= hat do not apply=C2=A0to having state in a GNAP URL.



3D""=E1=90=A7

=
On Thu, No= v 19, 2020 at 6:29 PM Fabien Imbault <fabien.imbault@gm= ail.com> wrote:
Hi Dick,=C2=A0

A requirement (must) brings the nice property that it = gives no ambiguity in the protocol. Having 2 ways of doing things here will= hurt more than it solves anything.

Or is there another linked issue you'd like to address (htt= p headers?) before we can close this one?=C2=A0

=
Thanks
Fabien=C2=A0

Le ven. 20 nov. 2020 =C3=A0 02:24, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
Let = me clarify -- putting state in what the client sends back to the AS is an i= mplementation choice. The protocol does not have to require it, or provide = it as an option.=C2=A0
3D""=E1=90=A7

On Thu, Nov = 19, 2020 at 5:20 PM Aaron Parecki <aaron= @parecki.com> wrote:
These statements are in conflict with each oth= er:

> I agree we should default to a secure stance an= d not rely on an implementer=C2=A0to deeply understand all the security con= siderations.
and
> In GNAP, putting state in an "acce= ss token" is an implementation choice.

If we = give people the option of doing something a less secure way (putting state = into the URL), then we have to explain all the security considerations of d= oing so. By not giving people the option (requiring the access token be sen= t in a header) then it's secure by default.

Th= e risk is if these URLs start containing state, e.g. a JWT, then the conten= ts of the payload may be visible by parties that were not expected to be ab= le to see them, which may have unintended consequences that are not obvious= right now.


On Thu, Nov 19, 2= 020 at 4:48 PM Dick Hardt <dick.har= dt@gmail.com> wrote:
I agree we should default to a secure stance a= nd not rely on an implementer=C2=A0to deeply understand all the security co= nsiderations.

There is a large difference though between= the effort in OAuth and having state in a URL in GNAP.

In OAuth, an implementation MUST put all the parameters=C2=A0into the= redirect. PAR allows an implementation to not have to do that.
<= br>
In GNAP, putting state in an "access token" is an i= mplementation choice. Given the client is authenticating on each subsequent= call, the server can maintain state on its side, which I think will be in = the vast majority of implementations.

wrt. state b= eing in the log -- without the client key, what are the risks that are diff= erent from seeing the URLs and methods?


=

3D""=E1=90=A7

On Thu, Nov 19, 2020 at= 6:55 AM Aaron Parecki <aaron@parecki.co= m> wrote:
You asked specifically what work in the OAuth group I wa= s referring to.=C2=A0

Wh= ile it=E2=80=99s true that those two concerns I pointed out in OAuth are mo= re specifically about the use of the front channel than the fact that the U= RL contains data, there are still concerns with putting data in URLs as poi= nted out already in this thread.

The most straightforward issue is that in practice there are ofte= n gateways or reverse proxies in front of servers and they may not be aware= of what=E2=80=99s behind them or that they should avoid logging certain th= ings. While it=E2=80=99s certainly possible to deploy this in a way that *i= s* secure and properly configure it to avoid logging where possible, or enc= rypt data in the URL instead of sign it and such, these seem like just addi= tional concerns that we=E2=80=99ll need to spell out in a security consider= ations section and are additional ways that an implementation may end up wi= th security issues.=C2=A0

Since we have the opportunity to recommend the best path for new developm= ents right now, it feels like we should be taking a more secure stance on t= his and avoid creating situations that we need to explain our way out of wh= ile we can.

Aaron Pareck= i



On Wed, Nov 1= 8, 2020 at 5:05 PM Dick Hardt <dick.h= ardt@gmail.com> wrote:
Got it, thanks!

As we kno= w, there is no certainty of who the originator=C2=A0of a redirect was, and = there is no assurance about the integrity or secrecy of the URL contents.

Those are not the case in GNAP with the client call= ing the AS -- so what is the risk of having information in the URL?

You had mentioned the information=C2=A0leaking into logs = -- but the AS controls those logs -- and the=C2=A0logs are a=C2=A0concern, = the=C2=A0AS could put an encrypted token in the URL.=C2=A0

=3D""=E1=90=A7

On Wed, Nov 18, 20= 20 at 3:38 PM Aaron Parecki <aaron@parec= ki.com> wrote:
I was referring to the work being done to reduce the= reliance on the front channel:

* Dropping the Implicit = grant
* Adding PAR to initiate an OAuth request from a POST reque= st instead of GET


On Wed, Nov 18, = 2020 at 3:04 PM Dick Hardt <dick.har= dt@gmail.com> wrote:
Hey Aaron,

In the WG me= eting you referenced work in the OAuth WG about removing data that is in UR= Ls for security reaasons. Would you elaborate on what you were referring to= ?

/Dick
3D""= =E1=90=A7
--
---<= /div>Aaron Parecki

--
TXAuth mailing list
TXAuth@ietf.org
https://www.= ietf.org/mailman/listinfo/txauth
--000000000000cecdab05b481e2ff-- From nobody Thu Nov 19 20:37: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 DD2F93A1840 for ; Thu, 19 Nov 2020 20:37:39 -0800 (PST) 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 JYiC7sVgx3z1 for ; Thu, 19 Nov 2020 20:37:37 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 9B7653A183F for ; Thu, 19 Nov 2020 20:37:37 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id y18so7400874ilp.13 for ; Thu, 19 Nov 2020 20:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZjAQ6gAzyzyvREpsLK5RFiHMyiHSLp7cgc7uNQ6yuhc=; b=mA97L/pAXG5gB6tJHK6z2UsoAtpntQnF+o5rv7RbZLn5mHGFVY2gV7UXOPxn1V/k1j PkWA/pzO+OsUBHt3FvStYKtxLOpp9pb4I8RGC6UKrFykx93R7S5y7/2npT8JJDGh0b4o Ia78vRUWqqgU4/gDj2o94k3vrYShfw6pJPBGtTxkTGvDGyj/BV0KmEpdfNY3gbHnBZco Mo60lS6eRlWbhJjRJ0h2LelbdPQ3HNuo8/lpAcpsUhUf/oGBVo+CdPdNBNP0Zs3dOIP8 6Et4CaN73UvfFA9Y9YDoFJHv5/WMxpRQEuRYgcBpqA3Kj3+XSZFKXyFx7GRaVHgkskEb h5KA== 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=ZjAQ6gAzyzyvREpsLK5RFiHMyiHSLp7cgc7uNQ6yuhc=; b=le3DNY+9UlOxGqdacoCf9U2LcRZAs2V2/H5R5NvJGFrRoG9mg5uqv7jULDqwD3b9YZ /re0u8VL6yMdjjjvX9duZSfnEXBsgZ+0cXKT38n+/UDZLn0nTpgtz/kLrURquaxCfxmR 8tl/KwtEDjChBpd4GLVSN24g+GAm91U63An/EyEcTjX4eE9BEtzddloH7vCSyP7s7tFV ta1GgW95tY0ehFl8l3RUtxLPvf6fZ8liEpCTk3meVnfKjHE/i1SrbN85rixXr11zis3R ky74GuTGPp9sMAJxLlu3dM9KJX/KD5dAsl9lGEphWND/cwM2rEpIoRSf4nsTQtbw7J4I wBxQ== X-Gm-Message-State: AOAM530lVMqQk7Jgl0qhmRzeBJ4ci3v5NrQpDzleSSqJE3feBbDKmyOI NI5f+sgMKW4SridT3C+xkI2S9VWxCXkQ5bX504k= X-Google-Smtp-Source: ABdhPJx8zRIcub/a2q51epwtgK/OxTB7h7fFR5mFljeQnFiSAf1MuKDUb9ogSvgjFDq5wuiDsRAEYvpuigZYBBCiZBI= X-Received: by 2002:a92:d489:: with SMTP id p9mr7820650ilg.123.1605847056777; Thu, 19 Nov 2020 20:37:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Fri, 20 Nov 2020 05:37:23 +0100 Message-ID: To: Dick Hardt Cc: Aaron Parecki , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000062081805b4826773" Archived-At: Subject: Re: [GNAP] security concerns / issues with data in URLs 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, 20 Nov 2020 04:37:40 -0000 --00000000000062081805b4826773 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great. Le ven. 20 nov. 2020 =C3=A0 05:00, Dick Hardt a =C3= =A9crit : > Got it. > > I have not yet had time to go over the issues and comment. I did look at > 67, and I have a fair amount of feedback on it that I hope to provide soo= n. > > =E1=90=A7 > > On Thu, Nov 19, 2020 at 7:17 PM Fabien Imbault > wrote: > >> I was referring to issue 67, discussed during the call (and during which >> Aaron made the comment you're discussing in the current thread). >> >> Fabien >> >> Le ven. 20 nov. 2020 =C3=A0 03:59, Dick Hardt a = =C3=A9crit : >> >>> Hi Fabien >>> >>> While I agree that a MUST removes ambiguity -- I'm not sure what issue >>> you are referring to that can be closed as I was not referring to any >>> specific issue. >>> >>> I was getting clarity on what the security issues were in having state >>> in the URL. >>> >>> The issue seems to be state information in logs. >>> >>> While the same issue exists with OAuth redirects, which were held up as >>> an example in the GNAP WG meeting, there are many more security issues = with >>> the OAuth redirect that do not apply to having state in a GNAP URL. >>> >>> >>> >>> =E1=90=A7 >>> >>> On Thu, Nov 19, 2020 at 6:29 PM Fabien Imbault >>> wrote: >>> >>>> Hi Dick, >>>> >>>> A requirement (must) brings the nice property that it gives no >>>> ambiguity in the protocol. Having 2 ways of doing things here will hur= t >>>> more than it solves anything. >>>> >>>> Or is there another linked issue you'd like to address (http headers?) >>>> before we can close this one? >>>> >>>> Thanks >>>> Fabien >>>> >>>> Le ven. 20 nov. 2020 =C3=A0 02:24, Dick Hardt a >>>> =C3=A9crit : >>>> >>>>> Let me clarify -- putting state in what the client sends back to the >>>>> AS is an implementation choice. The protocol does not have to require= it, >>>>> or provide it as an option. >>>>> =E1=90=A7 >>>>> >>>>> On Thu, Nov 19, 2020 at 5:20 PM Aaron Parecki >>>>> wrote: >>>>> >>>>>> These statements are in conflict with each other: >>>>>> >>>>>> > I agree we should default to a secure stance and not rely on an >>>>>> implementer to deeply understand all the security considerations. >>>>>> and >>>>>> > In GNAP, putting state in an "access token" is an implementation >>>>>> choice. >>>>>> >>>>>> If we give people the option of doing something a less secure way >>>>>> (putting state into the URL), then we have to explain all the securi= ty >>>>>> considerations of doing so. By not giving people the option (requiri= ng the >>>>>> access token be sent in a header) then it's secure by default. >>>>>> >>>>>> The risk is if these URLs start containing state, e.g. a JWT, then >>>>>> the contents of the payload may be visible by parties that were not >>>>>> expected to be able to see them, which may have unintended consequen= ces >>>>>> that are not obvious right now. >>>>>> >>>>>> --- >>>>>> Aaron Parecki >>>>>> https://aaronparecki.com >>>>>> >>>>>> >>>>>> On Thu, Nov 19, 2020 at 4:48 PM Dick Hardt >>>>>> wrote: >>>>>> >>>>>>> I agree we should default to a secure stance and not rely on an >>>>>>> implementer to deeply understand all the security considerations. >>>>>>> >>>>>>> There is a large difference though between the effort in OAuth and >>>>>>> having state in a URL in GNAP. >>>>>>> >>>>>>> In OAuth, an implementation MUST put all the parameters into the >>>>>>> redirect. PAR allows an implementation to not have to do that. >>>>>>> >>>>>>> In GNAP, putting state in an "access token" is an implementation >>>>>>> choice. Given the client is authenticating on each subsequent call,= the >>>>>>> server can maintain state on its side, which I think will be in the= vast >>>>>>> majority of implementations. >>>>>>> >>>>>>> wrt. state being in the log -- without the client key, what are the >>>>>>> risks that are different from seeing the URLs and methods? >>>>>>> >>>>>>> >>>>>>> >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> On Thu, Nov 19, 2020 at 6:55 AM Aaron Parecki >>>>>>> wrote: >>>>>>> >>>>>>>> You asked specifically what work in the OAuth group I was referrin= g >>>>>>>> to. >>>>>>>> >>>>>>>> While it=E2=80=99s true that those two concerns I pointed out in O= Auth are >>>>>>>> more specifically about the use of the front channel than the fact= that the >>>>>>>> URL contains data, there are still concerns with putting data in U= RLs as >>>>>>>> pointed out already in this thread. >>>>>>>> >>>>>>>> The most straightforward issue is that in practice there are often >>>>>>>> gateways or reverse proxies in front of servers and they may not b= e aware >>>>>>>> of what=E2=80=99s behind them or that they should avoid logging ce= rtain things. >>>>>>>> While it=E2=80=99s certainly possible to deploy this in a way that= *is* secure and >>>>>>>> properly configure it to avoid logging where possible, or encrypt = data in >>>>>>>> the URL instead of sign it and such, these seem like just addition= al >>>>>>>> concerns that we=E2=80=99ll need to spell out in a security consid= erations section >>>>>>>> and are additional ways that an implementation may end up with sec= urity >>>>>>>> issues. >>>>>>>> >>>>>>>> Since we have the opportunity to recommend the best path for new >>>>>>>> developments right now, it feels like we should be taking a more s= ecure >>>>>>>> stance on this and avoid creating situations that we need to expla= in our >>>>>>>> way out of while we can. >>>>>>>> >>>>>>>> Aaron Parecki >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Got it, thanks! >>>>>>>>> >>>>>>>>> As we know, there is no certainty of who the originator of a >>>>>>>>> redirect was, and there is no assurance about the integrity or se= crecy of >>>>>>>>> the URL contents. >>>>>>>>> >>>>>>>>> Those are not the case in GNAP with the client calling the AS -- >>>>>>>>> so what is the risk of having information in the URL? >>>>>>>>> >>>>>>>>> You had mentioned the information leaking into logs -- but the AS >>>>>>>>> controls those logs -- and the logs are a concern, the AS could p= ut an >>>>>>>>> encrypted token in the URL. >>>>>>>>> >>>>>>>>> =E1=90=A7 >>>>>>>>> >>>>>>>>> On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I was referring to the work being done to reduce the reliance on >>>>>>>>>> the front channel: >>>>>>>>>> >>>>>>>>>> * Dropping the Implicit grant >>>>>>>>>> * Adding PAR to initiate an OAuth request from a POST request >>>>>>>>>> instead of GET >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> Aaron Parecki >>>>>>>>>> https://aaronparecki.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hey Aaron, >>>>>>>>>>> >>>>>>>>>>> In the WG meeting you referenced work in the OAuth WG about >>>>>>>>>>> removing data that is in URLs for security reaasons. Would you = elaborate on >>>>>>>>>>> what you were referring to? >>>>>>>>>>> >>>>>>>>>>> /Dick >>>>>>>>>>> =E1=90=A7 >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>> --- >>>>>>>> Aaron Parecki >>>>>>>> https://aaronparecki.com >>>>>>>> >>>>>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> --00000000000062081805b4826773 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great.=C2=A0

Le ven. 20 nov. 2020 =C3=A0 05:00, Dick Hardt= <dick.hardt@gmail.com> a= =C3=A9crit=C2=A0:
Got it.

I have not yet had time to go over the issues a= nd comment. I did look at 67, and I have a fair amount of feedback=C2=A0on = it that I hope to provide soon.

3D""=E1=90= =A7

On Thu, Nov 19, 2020 at 7:17 PM Fabien Imbault <fabien.i= mbault@gmail.com> wrote:
I was referring to issue 67, discussed du= ring the call (and during which Aaron made the comment you're discussin= g in the current thread).

Fabi= en=C2=A0

Le ven. 20 nov. 2020 =C3=A0 03:59, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
Hi=C2=A0Fabien
=
While I agree that a MUST removes ambiguity -- I'm not s= ure what issue you are=C2=A0referring to that can be closed as I was not re= ferring to any specific issue.

I was getting clari= ty on what the security issues were in having state in the URL.=C2=A0
=

The issue seems to be state information in logs.
<= div>
While the same issue exists with OAuth redirects, which = were held up as an example in the GNAP WG meeting, there are many more secu= rity issues with the OAuth redirect that do not apply=C2=A0to having state = in a GNAP URL.



3D""=E1=90=A7

On Thu, Nov 19, 2020 at 6:29 PM Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" rel=3D"noreferrer noreferrer nor= eferrer" target=3D"_blank">fabien.imbault@gmail.com> wrote:
H= i Dick,=C2=A0

A requirem= ent (must) brings the nice property that it gives no ambiguity in the proto= col. Having 2 ways of doing things here will hurt more than it solves anyth= ing.

Or is there another= linked issue you'd like to address (http headers?) before we can close= this one?=C2=A0

Thanks<= /div>
Fabien=C2=A0

Le ven.= 20 nov. 2020 =C3=A0 02:24, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
Let me clarify -- putt= ing state in what the client sends back to the AS is an implementation choi= ce. The protocol does not have to require it, or provide it as an option.= =C2=A0
=E1=90=A7

On Thu, Nov 19, 2020 at 5:20 PM Aa= ron Parecki <aaron@parecki.co= m> wrote:
These statements are in conflict with each other:
> I agree we should default to a secure stance and not rely = on an implementer=C2=A0to deeply understand all the security considerations= .
and
> In GNAP, putting state in an "access token&qu= ot; is an implementation choice.

If we give people= the option of doing something a less secure way (putting state into the UR= L), then we have to explain all the security considerations of doing so. By= not giving people the option (requiring the access token be sent in a head= er) then it's secure by default.

The risk is i= f these URLs start containing state, e.g. a JWT, then the contents of the p= ayload may be visible by parties that were not expected to be able to see t= hem, which may have unintended consequences that are not obvious right now.=

---
A= aron Parecki


On Thu, Nov 19, 2= 020 at 4:48 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I agree we should default to a secu= re stance and not rely on an implementer=C2=A0to deeply understand all the = security considerations.

There is a large difference tho= ugh between the effort in OAuth and having state in a URL in GNAP.

In OAuth, an implementation MUST put all the parameters=C2= =A0into the redirect. PAR allows an implementation to not have to do that.<= /div>

In GNAP, putting state in an "access token&qu= ot; is an implementation choice. Given the client is authenticating on each= subsequent call, the server can maintain state on its side, which I think = will be in the vast majority of implementations.

w= rt. state being in the log -- without the client key, what are the risks th= at are different from seeing the URLs and methods?



3D""=E1=90=A7

On Thu, Nov 19, 20= 20 at 6:55 AM Aaron Parecki <= aaron@parecki.com> wrote:
You asked specifically what work in the = OAuth group I was referring to.=C2=A0

While it=E2=80=99s true that those two concerns I pointed out= in OAuth are more specifically about the use of the front channel than the= fact that the URL contains data, there are still concerns with putting dat= a in URLs as pointed out already in this thread.
The most straightforward issue is that in practice= there are often gateways or reverse proxies in front of servers and they m= ay not be aware of what=E2=80=99s behind them or that they should avoid log= ging certain things. While it=E2=80=99s certainly possible to deploy this i= n a way that *is* secure and properly configure it to avoid logging where p= ossible, or encrypt data in the URL instead of sign it and such, these seem= like just additional concerns that we=E2=80=99ll need to spell out in a se= curity considerations section and are additional ways that an implementatio= n may end up with security issues.=C2=A0

<= div dir=3D"auto">Since we have the opportunity to recommend the best path f= or new developments right now, it feels like we should be taking a more sec= ure stance on this and avoid creating situations that we need to explain ou= r way out of while we can.

Aaron Parecki



On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Got it, thanks!
As we know, there is no certainty of who the originator=C2= =A0of a redirect was, and there is no assurance about the integrity or secr= ecy of the URL contents.

Those are not the case in= GNAP with the client calling the AS -- so what is the risk of having infor= mation in the URL?

You had mentioned the informati= on=C2=A0leaking into logs -- but the AS controls those logs -- and the=C2= =A0logs are a=C2=A0concern, the=C2=A0AS could put an encrypted token in the= URL.=C2=A0

3D""=E1=90=A7

On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki <aaron@parecki.com> wrote:
I was referring to = the work being done to reduce the reliance on the front channel:

* Dropping the Implicit grant
* Adding PAR to initiate a= n OAuth request from a POST request instead of GET

---
Aaron Parecki
=

On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt &l= t;dick.hardt@gmail.com>= ; wrote:
Hey Aaron,

In the WG meeting you reference= d work in the OAuth WG about removing data that is in URLs for security rea= asons. Would you elaborate on what you were referring to?

/Dick
3D""= =E1=90=A7
--
---<= /div>Aaron Parecki

--
TXAuth mailing list
TXAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/txauth
--00000000000062081805b4826773-- From nobody Fri Nov 20 11:48: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 C1CB13A100F for ; Fri, 20 Nov 2020 11:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aFzPtUvD_4Ot for ; Fri, 20 Nov 2020 11:48:53 -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 3BB893A100E for ; Fri, 20 Nov 2020 11:48:52 -0800 (PST) Received: from [192.168.1.19] (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 0AKJmokD008793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 20 Nov 2020 14:48:51 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_4C74015C-33CE-4DE2-9DC3-AEBCE1323194" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <6692BEB7-7EBF-4289-9ED3-15DE83EE50DE@mit.edu> Date: Fri, 20 Nov 2020 14:48:50 -0500 To: GNAP Mailing List X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [GNAP] Access Token for Continuation API 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, 20 Nov 2020 19:48:55 -0000 --Apple-Mail=_4C74015C-33CE-4DE2-9DC3-AEBCE1323194 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 At Tuesday=E2=80=99s call, there was some general support for addressing = issue #67 (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/67 = ) by = requiring the =E2=80=9Ccontinue=E2=80=9D block of the response to = include an =E2=80=9Caccess_token=E2=80=9D field, and consequently = requiring the RC to present that access token when calling the = continuation request endpoint/API. In the current draft, the access = token is optional but the client is required to use the token if one is = given by the AS, so the optionality was really only on the AS side. The editors have made a pull request that makes the the access token = mandatory: https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 = This change hopefully also clarifies the nature of the access token = being bound to the RC=E2=80=99s key and presentation mechanism, which = means that the RC won=E2=80=99t need any additional functionality in = order to call the continuation endpoint since it uses the same = signing/proofing mechanisms that it did with its initial request.=20 Since the process for this WG is new, I want to point out that = =E2=80=9Cgeneral support=E2=80=9D in a meeting does not mean there is = necessarily consensus for this change. The pull request represents a = concrete proposal of changes that the editors believe would address this = issue. Please review the pull request and provide any suggestions for = better text for this issue. If you believe there is a better approach to = this issue (#67), please provide alternative text changes. Thanks, =E2=80=94 Justin --Apple-Mail=_4C74015C-33CE-4DE2-9DC3-AEBCE1323194 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 At = Tuesday=E2=80=99s call, there was some general support for addressing = issue #67 (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/67) by requiring the =E2=80=9Ccontinue=E2=80=9D block of the response to = include an =E2=80=9Caccess_token=E2=80=9D field, and consequently = requiring the RC to present that access token when calling the = continuation request endpoint/API. In the current draft, the access = token is optional but the client is required to use the token if one is = given by the AS, so the optionality was really only on the AS side.

The editors have made a = pull request that makes the the access token mandatory:

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

This change = hopefully also clarifies the nature of the access token being bound to = the RC=E2=80=99s key and presentation mechanism, which means that the RC = won=E2=80=99t need any additional functionality in order to call the = continuation endpoint since it uses the same signing/proofing mechanisms = that it did with its initial request. 

Since the process for this WG is new, I = want to point out that =E2=80=9Cgeneral support=E2=80=9D in a meeting = does not mean there is necessarily consensus for this change. The pull = request represents a concrete proposal of changes that the editors = believe would address this issue. Please review the pull request and = provide any suggestions for better text for this issue. If you believe = there is a better approach to this issue (#67), please provide = alternative text changes.

Thanks,
=E2=80=94 Justin

= --Apple-Mail=_4C74015C-33CE-4DE2-9DC3-AEBCE1323194-- From nobody Sat Nov 21 23:41: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 E18CF3A118E for ; Sat, 21 Nov 2020 23:41:00 -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, 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=mnot.net header.b=JT32bH3l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HKpRV9tx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pH3rzcz-PMlu for ; Sat, 21 Nov 2020 23:40:59 -0800 (PST) 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 E93AB3A1200 for ; Sat, 21 Nov 2020 23:40:58 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 7AC9A77B for ; Sun, 22 Nov 2020 02:33:11 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 22 Nov 2020 02:33:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=dKLXk81N9FMQlgbsLUptgmOLKjAfnMVh1mezboi6k2w=; b=JT32bH3l wwGQFttu4PGJJCxJETxRlzM8qnxn+RNih0Y/e/jCXaiRKCCXBCPK6WnrMBZkgPhe Du9Q6UNzZ4XvNifzsfWu5wHdF3qQk3BhDS694+R6HerCvCyCt4X5MBbXPHtDEthO HfG+1CATOfKZyaPiYzmwJ9BcvdlkcPeg0z5hTOjE107T+F2TsTaGGy9c4B/RWGCJ AseXvjBpdaoTARq8hALUaQXuf2XzcUI4TmgIaCyXVFEoF5Xk7N9jD3zVxrwUbFiw LedaUL+6KFbGAF92w4Q/rceUCYsRHHXsieclAk76QXR30bmvyCOXjCNUpr18vNlx uDTo1mE/D2CWHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=dKLXk81N9FMQlgbsLUptgmOLKjAfn MVh1mezboi6k2w=; b=HKpRV9txjuvK4MrVTCGPw5MANJTYsGgT0qupM+y6381kv EepSvqRTYNI1tdqDhZNGIPFwF9Gg1EwE0BEM+F6pbA/c1eez19DXGeG17PxxyeB8 QTYMACTwRHrz6l2x484IQrCtHJIhGZhYEu8rqc68DqLpFxngXK/ayLuqidV2XRAn tFiTB0RwAEmWvQw19WyMVcCt/47J1XwgOyCVowPNWQkf73gbUDb0iR+5vnEsye6z QzbsTietw5+yaYljOnkLm74QthauFDd6vaoj1F9HcPJR3Cwip2UOxPpBQTDxwu5u lp21vW68YGqnCmDPAMch8wnQiIsqKTPMlEfU9U+YQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegfedguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudeijedrudeivd druddtjeenucevlhhushhtvghrufhiiigvpeehnecurfgrrhgrmhepmhgrihhlfhhrohhm peguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az12-368.internal.cloudapp.net (unknown [52.167.162.107]) by mail.messagingengine.com (Postfix) with ESMTPA id DDFB13064AAA for ; Sun, 22 Nov 2020 02:33:10 -0500 (EST) Content-Type: multipart/alternative; boundary="===============1220513847899552141==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20201122073310.DDFB13064AAA@mailuser.nyi.internal> Date: Sun, 22 Nov 2020 02:33:10 -0500 (EST) 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, 22 Nov 2020 07:41:01 -0000 --===============1220513847899552141== 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 (+3/-3/=F0=9F=92=AC53) 3 issues created: - Identify editor's notes that are just comments (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/128=20 - Stable URL for =E2=80=9CDisplay of a Short User Code=E2=80=9D (by aaron= pk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/123=20 - Group interaction mode flags (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/122=20 21 issues received 53 new comments: - #128 Identify editor's notes that are just comments (6 by fimbault, jri= cher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/128=20 - #123 Stable URL for =E2=80=9CDisplay of a Short User Code=E2=80=9D (1 b= y jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/123=20 - #122 Group interaction mode flags (2 by fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/122=20 - #121 Redirect to an Arbitrary Shortened URL (5 by aaronpk, davidgtonge,= fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/121=20 - #118 RS www-authenticate response (3 by davidgtonge, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/118=20 - #111 Key redundancy in DPoP method (1 by davidgtonge) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/111=20 - #109 Modification of content type by attached JWS signature method (3 b= y davidgtonge, jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109=20 - #86 Default polling wait time (3 by fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/86=20 - #68 Syntax for single and multiple access tokens (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/68=20 - #67 Continuation API artifact structure (4 by fimbault, jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/67=20 - #62 Referencing an existing grant request (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/62=20 - #48 Logo by value (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/48=20 - #42 Use of identifiers as communication channels (3 by aaronpk, jricher= , yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/42=20 - #39 Token flags (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/39=20 - #36 Requesting resources by reference (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36=20 - #32 Names for Roles (3 by fimbault, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/32=20 - #29 Terminology (6 by fimbault, jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29=20 - #21 The App Option (1 by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/21=20 - #8 Terminology: Key (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/8=20 - #6 Polymorphism (5 by davidgtonge, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/6=20 - #5 Is it `cert#256` or `cert#S256`? The document has both, and I suppos= e one is a typo. (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/5=20 3 issues closed: - Is it `cert#256` or `cert#S256`? The document has both, and I suppose o= ne is a typo. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/5=20 - Terminology: Key https://github.com/ietf-wg-gnap/gnap-core-protocol/iss= ues/8=20 - Names for Roles https://github.com/ietf-wg-gnap/gnap-core-protocol/issu= es/32=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+5/-5/=F0=9F=92=AC0) 5 pull requests submitted: - Make access token mandatory for continuation API calls. (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129=20 - Changelog 02 (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/127=20 - minor typo fixes (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/126=20 - rephrase to "GNAP" instead of "GNAP protocol" (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/125=20 - added type markers for protocol elements (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/124=20 5 pull requests merged: - Changelog 02 https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/127=20 - rephrase to "GNAP" instead of "GNAP protocol" https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/125=20 - minor typo fixes https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/126=20 - added type markers for protocol elements https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/124=20 - Minor cleanup, fix dangling statement. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/120=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============1220513847899552141== 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 November 22, 2020

Events without label "editorial"

Issues

ietf-wg-gnap/core-protocol (+3/-3/=F0=9F=92=AC53)

3 issues created:

21 issues received 53 new comments:

3 issues closed:

Pull requests

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

5 pull requests submitted:

5 pull requests merged:

Repositories tracked by this digest:

--===============1220513847899552141==-- From nobody Sun Nov 22 17:06: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 03AE13A10DD for ; Sun, 22 Nov 2020 17:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.514 X-Spam-Level: X-Spam-Status: No, score=0.514 tagged_above=-999 required=5 tests=[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=0.7, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 B9N8eyL5szoP for ; Sun, 22 Nov 2020 17:06:34 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FA43A10DE for ; Sun, 22 Nov 2020 17:06:34 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id s27so1536485lfp.5 for ; Sun, 22 Nov 2020 17:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7a2O0GjJt4NXYmP7IUk0S9IzeE8bNDrBOnKubvdB7d4=; b=V+6TDdt6enWEW+6ItaVGhfTNDqTQS44UFvwX0cGXqSIl5tVq4Tv/WtBeg7BbY5YCHs Nkr45XrhKB3JS8IJwkHgqYToyrhjVAMytnhCwmLdj31R/nYqbLhsQ8Fl/z73wglghGDP P4CDR5sx0YOHr+9dbqssfxk+RBtolboHEv/SkFRRhokjsKA0x8uzsV+1HMoch3BsOGGC 3vRxN+RQrNnUo+QztM8g/Z3O63AIuwSMHNB0vnFgA3Gu344vIMaBnFR6paT+DD5S9m8s 4zth/wqLvrzE5UCylG+k0clZfLUDQU/Rs+sU5PYljTCrkriyyEL78Idh8QbI9//TeuvM 638Q== 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=7a2O0GjJt4NXYmP7IUk0S9IzeE8bNDrBOnKubvdB7d4=; b=XBLGkLNPzVxBTeG95HhsknJH21aPJoRjNP5ybUbC+WgpORleXVa0dzPXPS1aS76YUr 9I+DIW3Wp6eQcUub98bnRd3oV8RbbJHzyTQgceNSt5iz53zmUGWOqFsMyb4+KuXUvpgp dAWqKGg65q/Sf9XCkqtJn6pA2BUMESrTEeD8yIQdTsOaQQ1Aiw6HfMC9q0qtnWUFZ7Hl 620cXMKFh1ZXWUlnuemowkAf+VzxNoAs182/BsXMyGPnIRG9J8F9l6v/U7s97Z7xlj5e Vp/N9g0rJKZtfOR8ayHU5VMoaJaOv3XdWgngAx3wPu7zC+nuYHldO1jpfcvLSX9Wc8rE I2xQ== X-Gm-Message-State: AOAM533IlaCADGsyHu8IdRqSOFF9WwPyOue3ZR9K1yO3ft3EEw/TPzxJ sjLCK3/6XHpm20ZQfkPp45qWGfSS3ipdwdhnP4W/VbHOrhmjBA== X-Google-Smtp-Source: ABdhPJwCgOQ96AgKhKVwxcy04/wFr0vDsVDbd28hDtpiaOcC34lamytxl5hPGXSj6WI7/h5yQJyjbzYm9Ii3nbOlyks= X-Received: by 2002:a19:6b02:: with SMTP id d2mr11315091lfa.221.1606093591974; Sun, 22 Nov 2020 17:06:31 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Sun, 22 Nov 2020 17:05:55 -0800 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000006998c05b4bbcefb" Archived-At: Subject: [GNAP] "Access Token" when calling AS is really a cookie 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: Mon, 23 Nov 2020 01:06:36 -0000 --00000000000006998c05b4bbcefb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When I look at how GNAP is using access tokens for continuation requests, and the pull request #129 Those "access tokens" look a lot more like cookies (managing state) than how access tokens are usually used (representing authorization). See table below. If there is a real requirement for passing state back and forth between a server (the AS in this case) and the client when making API calls, then I suggest that is out of scope for GNAP as I see it being a general purpose mechanism for any API. /Dick *cookies*- issued by server being accessed - are not presented to other servers - issued after first access - may be different for different URLs - may be updated on each access - represents the context of a session (state) *access tokens*- issued by an independent service (AS) - may be used at any URL at the RS - new ones issued by AS as needed - represents authorization granted to a client at an RS =E1=90=A7 --00000000000006998c05b4bbcefb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When I look at how GNAP is using access tokens for co= ntinuation requests, and the pull request=C2=A0#129

Those &q= uot;access tokens" look a lot more like cookies (managing state) than = how access tokens are usually used (representing authorization). See table = below.

If there is a real requirement for passing = state back and forth between a server (the AS in this case) and the client = when making API calls, then I suggest that is out of scope for GNAP as I se= e it being a general=C2=A0purpose mechanism for any API.

/Dick


cookies
- issued by ser= ver being accessed
- are not presented to other servers
- issued afte= r first access
- may be different for different URLs
- may be updated= on each access
- represents the context of a session (state)

= access tokens
- issued by an independent service (AS)
- may be us= ed at any URL at the RS
- new ones issued by AS as needed
- represent= s authorization granted to a client at an RS
3D""=E1=90= =A7
--00000000000006998c05b4bbcefb-- From nobody Sun Nov 22 23:40: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 3B05A3A1684 for ; Sun, 22 Nov 2020 23:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_BLOCKED=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 qnnGWtoM5pBN for ; Sun, 22 Nov 2020 23:40:45 -0800 (PST) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 808A53A167E for ; Sun, 22 Nov 2020 23:40:45 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id f23so21911812ejk.2 for ; Sun, 22 Nov 2020 23:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pIk8OLnNzyq70PSLfgzLdZddBokTuaVyQClXHYE4K90=; b=NynI0oNC+X8VW5V2XPKLMz1WTgcXMqQmjzEiY22pmgIy3kF2dUJOWH5KjSUQMjGX+V a1VMjmxwY3ycU93SgqZplLFA3LQr5/CNyF4FMjiqKlaPWUC/Mjdmq+Of76e9fG6yZdmj rhW7LzEfI9Qxe/uxuKg8JxMRamw10MWAGLwuwksN/m0iLzOtMr6FV9iTBd0UIj+P9cU1 aYW2WRLwWJP5V0ngivAvfbnwmYr7CjlvnHfYK44dszZrlzvJfWCy5lW0Ky3GsLj+ng1w UI7r0j7q6PSjJiSeOeuTDq8bUFf4Lpnw9TEcYb5a2VY72Gd8F/gdSDWaSle5KkndaxYM m9kg== 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=pIk8OLnNzyq70PSLfgzLdZddBokTuaVyQClXHYE4K90=; b=Bntp1ptLG2AlJuseOMU46s4w4EH4J2n/ygQKdoGAxr2V5/5aeiGeHFVdn5suUcN5K/ EXnlRD99fRqpPT6JYJ3w43pLLRowGUebXPN18S+HNHdjRIbs0fbQG6kBrvQLjtpffkIc acIShXkuf4NIrbvBn2YeI1t4kuHAZ9r76S6iY6h+vOnNXqMgjzmMriT9SeKsPwUH765W Y3ncSYPU7NP7jsNG8X+o6VfOVK6qDEgTH2IsELzjAu6Wfgsmg7xU6UgDb9+jipwwuSxx jqkD8lm9LQp2/qtemTrolr7Q10cp4AMlr2RcPerd2evxa0RvdNOf36PpnaTUjeoTIiJl CkUQ== X-Gm-Message-State: AOAM53369Ra1MsdwXmLdO5lQXJcTypyVgKjj+BEOP+m+Y5ix/xrigvEa FNRjVQPVkwWg7Otsndmo10JOXQT58J3oHPHlETU= X-Google-Smtp-Source: ABdhPJxMh0sFO9mFwB7vSlKGBzm+3wLZLp6K2k7yBitwmkI8kRZHqKr2DYSGhf4oxFrzIq3f9zGTf1wWDun8QyfCFgA= X-Received: by 2002:a17:906:3704:: with SMTP id d4mr6950010ejc.338.1606117243799; Sun, 22 Nov 2020 23:40:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 23 Nov 2020 08:40:31 +0100 Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000c8ce5805b4c14f0c" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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: Mon, 23 Nov 2020 07:40:47 -0000 --000000000000c8ce5805b4c14f0c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dick, In GNAP, the client isn't managing state (unlike a web app), the entire point is that the lifecycle should be managed by the AS. As in any state machine, there are states and transitions. Here we're not passing state, merely expressing "please continue". The client can be completely unaware of the underlying state. In effect the client only has the ability to ask the server to generate the next transition. So I don't think you can compare that to cookies. It's a different behavior. BTW if it was the case it would lead to a whole new class of issues, because there's an entire legal framework around cookies... To avoid confusion with a standard access token, we have the "key" field. My proposal would be to make it more explicitly (cf comment in issue 67). Fabien Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt a =C3= =A9crit : > When I look at how GNAP is using access tokens for continuation requests, > and the pull request #129 > > > Those "access tokens" look a lot more like cookies (managing state) than > how access tokens are usually used (representing authorization). See tabl= e > below. > > If there is a real requirement for passing state back and forth between a > server (the AS in this case) and the client when making API calls, then I > suggest that is out of scope for GNAP as I see it being a general purpose > mechanism for any API. > > /Dick > > > > *cookies*- issued by server being accessed > - are not presented to other servers > - issued after first access > - may be different for different URLs > - may be updated on each access > - represents the context of a session (state) > > > *access tokens*- issued by an independent service (AS) > - may be used at any URL at the RS > - new ones issued by AS as needed > - represents authorization granted to a client at an RS > =E1=90=A7 > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000c8ce5805b4c14f0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,

In = GNAP, the client isn't managing state (unlike a web app), the entire po= int is that the lifecycle should be managed by the AS.=C2=A0

As in any state machine, there are st= ates and transitions. Here we're not passing state, merely expressing &= quot;please continue". The client can be completely unaware of the und= erlying state.=C2=A0
In effect the client only has the ability to ask the server to gene= rate the next transition.

So I don't think you can compare that to cookies. It's= a different behavior. BTW if it was the case it would lead to a whole new = class of issues, because there's an entire legal framework around cooki= es...=C2=A0

To avoid con= fusion with a standard access token, we have the "key" field. My = proposal would be to make it more explicitly (cf comment in issue 67).

Fabien=C2=A0


Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
When I look at how GNAP= is using access tokens for continuation requests, and the pull request=C2= =A0#129

Those "acc= ess tokens" look a lot more like cookies (managing state) than how acc= ess tokens are usually used (representing authorization). See table below.<= /div>

If there is a real requirement for passing state b= ack and forth between a server (the AS in this case) and the client when ma= king API calls, then I suggest that is out of scope for GNAP as I see it be= ing a general=C2=A0purpose mechanism for any API.

= /Dick


cookies
- issued by server bei= ng accessed
- are not presented to other servers
- issued after first= access
- may be different for different URLs
- may be updated on eac= h access
- represents the context of a session (state)

access = tokens
- issued by an independent service (AS)
- may be used at a= ny URL at the RS
- new ones issued by AS as needed
- represents autho= rization granted to a client at an RS
3D""=E1=90=A7
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--000000000000c8ce5805b4c14f0c-- From nobody Mon Nov 23 04:53: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 3FE833A0A3B for ; Mon, 23 Nov 2020 04:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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 35y5QMcM975x for ; Mon, 23 Nov 2020 04:53:27 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 9756E3A0A35 for ; Mon, 23 Nov 2020 04:53:27 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id f5so14864172ilj.9 for ; Mon, 23 Nov 2020 04:53:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bKMirIbryF8gOFYzDvnwXzTrSDTSFuh3dekqcOsEFC4=; b=kGLS8/qwFyJKksEWaDwFijnkivIlvX4PqmQuxH1m72e817eSh+IboAWNHwqiGCcAjP yYlLtWsqEfOpG8Te2F71+cB+wpPheM3lp5nRvxCac2hcdVolZ1CuOeA06WbUMaft4hbI RTV4PK+KwykWoL2y4Am0OVyWP6eVsFQBEgXfemh+6auJ0+j+riOtvchienrpG7egMIES Vx2GzlwncLe/+LcGSbzcusPF1EG6AJ13lNM8Pc3ghEJt7QE3soqROd3T4LvQW5Udc0Cv Mzz6zMEwfrM0PwCWaqnX/rDlZI+wFGbfQ21EJNR7Kjc6fGhB5hh5vbHP58ptgxi23lJ9 ZlSg== 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=bKMirIbryF8gOFYzDvnwXzTrSDTSFuh3dekqcOsEFC4=; b=QXEH8VL5DI5NAQbvIMgpxZptDEPhmEhtIA8V+Lru+uWuxPhrbLqhf0F9HT0hVq6hCq 7Qf5fhhbzKHtqlMI135vvZ581sZZfKOMfcsDFNRzSOOYIAi2C/wBZxvaiXqHou61Rpom jlQZT0dpz8j6A57X+/i82br41qxgMhbCS3MfNjDKiBd2WbB02HBLBxsZjtSuIPHgDjBv AlsCDwzb6Bd4z3rJ0kAssRffDtCC4Q8nWikWBPAoL5lU6BExMux8sm9ixFDfGdsVo+fK hLOyI7CRyX8R5yuX8+IN8uVvioduD0vshbCSGcDgAtbFlrmHDMZ3FbE1xT7bMlnODDOt C8wA== X-Gm-Message-State: AOAM530Fq3BaYI3mCyX0n9DH8f/WC9okMrRTh44+AJFVOYjVUtEEoITV Of5FCOdHpTivTU67W0AYRBs0AzZRak/oLj97zWw= X-Google-Smtp-Source: ABdhPJwLOTv1TYMQ1vpUx+xU769mrUF+E0tyvdda5IeoR39lNxZ3UcE1cRDhpRFmfrdvPer2kk8vAplD7/qvEKCtof0= X-Received: by 2002:a92:89d3:: with SMTP id w80mr32089964ilk.68.1606136006653; Mon, 23 Nov 2020 04:53:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 23 Nov 2020 13:53:15 +0100 Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000023432405b4c5ae51" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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: Mon, 23 Nov 2020 12:53:29 -0000 --00000000000023432405b4c5ae51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, Following Justin's feedback, I made an alternative proposal: make the key verification the default everywhere, and allow bearer tokens for resources access only when set explicitly. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/67#issuecomment-7= 32119398 I believe this removes the confusion. Fabien On Mon, Nov 23, 2020 at 8:40 AM Fabien Imbault wrote: > Hi Dick, > > In GNAP, the client isn't managing state (unlike a web app), the entire > point is that the lifecycle should be managed by the AS. > > As in any state machine, there are states and transitions. Here we're not > passing state, merely expressing "please continue". The client can be > completely unaware of the underlying state. > In effect the client only has the ability to ask the server to generate > the next transition. > > So I don't think you can compare that to cookies. It's a different > behavior. BTW if it was the case it would lead to a whole new class of > issues, because there's an entire legal framework around cookies... > > To avoid confusion with a standard access token, we have the "key" field. > My proposal would be to make it more explicitly (cf comment in issue 67). > > Fabien > > > Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt a = =C3=A9crit : > >> When I look at how GNAP is using access tokens for continuation requests= , >> and the pull request #129 >> >> >> Those "access tokens" look a lot more like cookies (managing state) than >> how access tokens are usually used (representing authorization). See tab= le >> below. >> >> If there is a real requirement for passing state back and forth between = a >> server (the AS in this case) and the client when making API calls, then = I >> suggest that is out of scope for GNAP as I see it being a general purpos= e >> mechanism for any API. >> >> /Dick >> >> >> >> *cookies*- issued by server being accessed >> - are not presented to other servers >> - issued after first access >> - may be different for different URLs >> - may be updated on each access >> - represents the context of a session (state) >> >> >> *access tokens*- issued by an independent service (AS) >> - may be used at any URL at the RS >> - new ones issued by AS as needed >> - represents authorization granted to a client at an RS >> =E1=90=A7 >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --00000000000023432405b4c5ae51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe this removes the confusion.=C2=A0
Fabien

On Mon, Nov 23, 2020 at 8:40 AM Fabien Imbault <= ;fabien.imbault@gmail.com&g= t; wrote:
Hi Dick,

In GNAP, = the client isn't managing state (unlike a web app), the entire point is= that the lifecycle should be managed by the AS.=C2=A0

As in any state machine, there are states an= d transitions. Here we're not passing state, merely expressing "pl= ease continue". The client can be completely unaware of the underlying= state.=C2=A0
In effect the client only has the ability to ask the server to generate th= e next transition.

So I don't think you can compare that to cookies. It's a diff= erent behavior. BTW if it was the case it would lead to a whole new class o= f issues, because there's an entire legal framework around cookies...= =C2=A0

To avoid confusio= n with a standard access token, we have the "key" field. My propo= sal would be to make it more explicitly (cf comment in issue 67).

Fabien=C2=A0


Le l= un. 23 nov. 2020 =C3=A0 02:06, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2= =A0:
When I look at how GNAP is using access tokens for continuation = requests, and the pull request=C2=A0#129

Those "access tokens" look a lot more like cook= ies (managing state) than how access tokens are usually used (representing = authorization). See table below.

If there is a rea= l requirement for passing state back and forth between a server (the AS in = this case) and the client when making API calls, then I suggest that is out= of scope for GNAP as I see it being a general=C2=A0purpose mechanism for a= ny API.

/Dick


cook= ies
- issued by server being accessed
- are not presented to othe= r servers
- issued after first access
- may be different for differen= t URLs
- may be updated on each access
- represents the context of a = session (state)

access tokens
- issued by an independent s= ervice (AS)
- may be used at any URL at the RS
- new ones issued by A= S as needed
- represents authorization granted to a client at an RS
<= /div>
=3D""=E1=90=A7
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--00000000000023432405b4c5ae51-- From nobody Mon Nov 23 08:09: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 ED7363A03FC for ; Mon, 23 Nov 2020 08:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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 tAKDSeq3lz3Y for ; Mon, 23 Nov 2020 08:09:11 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450: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 7CFAA3A03F8 for ; Mon, 23 Nov 2020 08:09:11 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id o24so18571594ljj.6 for ; Mon, 23 Nov 2020 08:09:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=28IC1gatJrmEoVLBdEv/dAs7B6PD6CxceCSgomr1GEA=; b=LM74lpy9vq/64A1B4QF06JlDwHpgfJjF0Ks8Mhn+fiz9NJ3xtwdCQXUuZb6MZeYIdD TObkV+IpPhFmWiyyQ3dBmxbB6IPSXpOFah7+RFI/oq3k8maDoo/ncohcp3+3nszNkhtO VfG7zPcMH9oq/GK08f21ZUZwEzuHvwcVUH80SC5tBbu/JPSN4qtbfXjVldkuLLhOjppZ z3MUivT7xXwIPSQioTbcgOmmtwTOiKeBeK5q+VQOWzEx3A/R00APfx//f94DCuI+nnLV WNvXiKF6Ydb8jumQjJW5ITkKtFfmFY6LNnfQueMiG2xRWGCAMJECE44qiJDsbIO+hFyj XV6A== 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=28IC1gatJrmEoVLBdEv/dAs7B6PD6CxceCSgomr1GEA=; b=B2hq9HAzI7rQqvrtmnzcSbrrmOuKxvsVNW+euOgIpLgqxDSzIDLQ5+f160+jOLaqNz deHpJE4BmmZhfCboX9Ess+nk/CxAHT4KbzALXA4ivWiZbjX9uxp1cnp4+fLpFBBF/dn2 +D2FMcjp/RUmgdfTBgOsdyniF+GyqpcfhglbCf8NzoRn+GJERDa6A+Fv/xxUIQmvF5Lz 7AFXC/mxwp92VhvxiFrc6xyO9PjpNO/uRNkYstp0ZmQMJu3PrypmkN2wSw2e+qF56zSG dQFf5QWagtFw3+yZhYstQO8VRlwHj0MkS7VG9UV0EA5Md+CWseS1EnxUUhKgihrPc/I7 BrjQ== X-Gm-Message-State: AOAM531AuZ/nPbIik7A9lbAdcjql/mBKhEilmc44HVyB+LTvXHBFfVRb /LPXDP1KOC79zO1RpVKhc6LHEK2/lAhXhAORtxAVlSrd8Lw= X-Google-Smtp-Source: ABdhPJxwwy8PkiDrYBJDfKRALy3tJOUmyfaiHW4Bq7pmcZwiCX2iWllyktmogl60Pk1+YkVqoA8I/ZxiwBy7ukw7pEA= X-Received: by 2002:a2e:7a0a:: with SMTP id v10mr46126ljc.5.1606147749367; Mon, 23 Nov 2020 08:09:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 23 Nov 2020 08:08:32 -0800 Message-ID: To: Fabien Imbault Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000000ed33505b4c86ad2" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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: Mon, 23 Nov 2020 16:09:14 -0000 --0000000000000ed33505b4c86ad2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If all the access token is doing is expressing "please continue" ... why do we need an access token? Why not just have a unique URL for the grant request? The URL is the identifier for the grant request that allows the client to delete, update, etc. How the access token is being used is just like a cookie. The AS gives a string to the client and the client must pass the string back to the AS when it calls it, the AS may then give a new string to the client for the next call. Works like a cookie. I don't know why you think there are legal issues around this. /Dick =E1=90=A7 On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault wrote: > Hi Dick, > > In GNAP, the client isn't managing state (unlike a web app), the entire > point is that the lifecycle should be managed by the AS. > > As in any state machine, there are states and transitions. Here we're not > passing state, merely expressing "please continue". The client can be > completely unaware of the underlying state. > In effect the client only has the ability to ask the server to generate > the next transition. > > So I don't think you can compare that to cookies. It's a different > behavior. BTW if it was the case it would lead to a whole new class of > issues, because there's an entire legal framework around cookies... > > To avoid confusion with a standard access token, we have the "key" field. > My proposal would be to make it more explicitly (cf comment in issue 67). > > Fabien > > > Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt a = =C3=A9crit : > >> When I look at how GNAP is using access tokens for continuation requests= , >> and the pull request #129 >> >> >> Those "access tokens" look a lot more like cookies (managing state) than >> how access tokens are usually used (representing authorization). See tab= le >> below. >> >> If there is a real requirement for passing state back and forth between = a >> server (the AS in this case) and the client when making API calls, then = I >> suggest that is out of scope for GNAP as I see it being a general purpos= e >> mechanism for any API. >> >> /Dick >> >> >> >> *cookies*- issued by server being accessed >> - are not presented to other servers >> - issued after first access >> - may be different for different URLs >> - may be updated on each access >> - represents the context of a session (state) >> >> >> *access tokens*- issued by an independent service (AS) >> - may be used at any URL at the RS >> - new ones issued by AS as needed >> - represents authorization granted to a client at an RS >> =E1=90=A7 >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000000ed33505b4c86ad2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If all the access token is doing is expressing "pleas= e continue" ... why do we need an access token?

Why= not just have a unique=C2=A0URL for the grant request? The URL is the iden= tifier for the grant request that allows the client to delete, update, etc.=

How the access token is being used is just like a= cookie. The AS gives a string to the client and the client must pass the s= tring back to the AS when it calls it,=C2=A0the AS may then give a new stri= ng=C2=A0to the client for the next call. Works like a cookie. I don't k= now why you think there are legal issues around this.=C2=A0

<= /div>
/Dick



3D""=E1=90=A7

On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault <= fabien.imbault@gmail.com>= ; wrote:
Hi Dick,

In GNAP, t= he client isn't managing state (unlike a web app), the entire point is = that the lifecycle should be managed by the AS.=C2=A0

As in any state machine, there are states and= transitions. Here we're not passing state, merely expressing "ple= ase continue". The client can be completely unaware of the underlying = state.=C2=A0
= In effect the client only has the ability to ask the server to generate the= next transition.

So I don't think you can compare that to cookies. It's a diffe= rent behavior. BTW if it was the case it would lead to a whole new class of= issues, because there's an entire legal framework around cookies...=C2= =A0

To avoid confusion w= ith a standard access token, we have the "key" field. My proposal= would be to make it more explicitly (cf comment in issue 67).

Fabien=C2=A0


Le lun.= 23 nov. 2020 =C3=A0 02:06, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:<= br>
When I look at how GNAP is using access tokens for continuation reque= sts, and the pull request=C2=A0#129
Those "access tokens" look a lot more like cookies (= managing state) than how access tokens are usually used (representing autho= rization). See table below.

If there is a real req= uirement for passing state back and forth between a server (the AS in this = case) and the client when making API calls, then I suggest that is out of s= cope for GNAP as I see it being a general=C2=A0purpose mechanism for any AP= I.

/Dick


cookies- issued by server being accessed
- are not presented to other ser= vers
- issued after first access
- may be different for different URL= s
- may be updated on each access
- represents the context of a sessi= on (state)

access tokens
- issued by an independent servic= e (AS)
- may be used at any URL at the RS
- new ones issued by AS as = needed
- represents authorization granted to a client at an RS
=
3D""==E1=90=A7
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--0000000000000ed33505b4c86ad2-- From nobody Mon Nov 23 08:30: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 4EF213A099E for ; Mon, 23 Nov 2020 08:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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 1ETXtbbszn2l for ; Mon, 23 Nov 2020 08:30:11 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 99FAF3A0997 for ; Mon, 23 Nov 2020 08:30:11 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id r17so4520227ilo.11 for ; Mon, 23 Nov 2020 08:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fBclA3/E57SPl+5Ywdny++4ikym9R4bzCethfJWA5xo=; b=SYTgP0IRLVnZ+jBibi9Wvp1enDm8sLG8j+o718Q8Yk73lN57ZS15XFnyyHQm31AFRg KRPCrrncUPPaTntOiZ3BsXoV2cnsw1WtdfuqnWwPuPF+Z+5MukDvBeOmXj4WdliiDUma pK9iDIEu+935qEzm/ZyjAEacZu/SGnKz1CLAxLw4lBPpxmYn//FotRBCHCo4b3IRgH2M VPQ5Tjz6qZqjR9ddAgxwckpBQbiHsRNt1YAsWHZQbrUrHvMEt8tabBfk95oqZjXiHEPH 5rDD1nBbMjSt6hPHShWLH+qMCaWNDbGgz6ci0yqbj5UGPQAe+pDrSkbf7bz62aoTBih+ lxrA== 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=fBclA3/E57SPl+5Ywdny++4ikym9R4bzCethfJWA5xo=; b=gPwgZy/Pouz7amHKoxUV3SbpEzen/a22vJVE1Fcy7OrM/UEU71x1xjRFAj4ytwWTDn FQUVlOSONci2bdIs7mYxhWVHMu02xHwh7Gc7FrB/v9n8pX+2p33FWGjVdgFhSyioFgmZ P3Yx4C4Pg3C7aaEMAORNrVvs1JRJMTS9p0nBKxAfa3n/hv6dGqwtwMvaWeQ4fnLgx0H0 OhN+2ETPv4JDZvmHFLOuSVNOX1t9E0+HMsFfS4/IvbRLBQ/C2jVe6v2cTPWMnyHcul1N QRSllvQP/gsJDJlCqKakUrbtAp+DNyAmE+kRhhX4VdBiXpDTijLLqXpu0lu4Gu/7NkhX jX5g== X-Gm-Message-State: AOAM532CA2cHr5BQ9XfSrCInvzmX6yFgvBG2C0d9SxwbOsTJqoTL94WH qsjrQn34b4g13+8X80Ki7kgZCb2IMQ7m5Y/FPMk= X-Google-Smtp-Source: ABdhPJypmnEe4Tx2HjcvB+tpKIkVAKafAqgIjwmlGSEtYfxxd3lUOXn3IC0fCPpc3WzJo8FEE79AvOK9mVvGbQFnLKE= X-Received: by 2002:a92:6b05:: with SMTP id g5mr478935ilc.289.1606149010922; Mon, 23 Nov 2020 08:30:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 23 Nov 2020 17:29:59 +0100 Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000409fd505b4c8b582" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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: Mon, 23 Nov 2020 16:30:13 -0000 --000000000000409fd505b4c8b582 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If the client was directly managing/storing its state, then it would indeed effectively work as a cookie. But here the access token merely provides a map to the current state (opaque to the client), as managed/controlled by the AS. It's a very different use case compared to what cookies are used for in webapps. Having a unique URL is a different design (XAuth was more aligned with that idea). Fabien On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt wrote: > If all the access token is doing is expressing "please continue" ... why > do we need an access token? > > Why not just have a unique URL for the grant request? The URL is the > identifier for the grant request that allows the client to delete, update= , > etc. > > How the access token is being used is just like a cookie. The AS gives a > string to the client and the client must pass the string back to the AS > when it calls it, the AS may then give a new string to the client for the > next call. Works like a cookie. I don't know why you think there are lega= l > issues around this. > > /Dick > > > > =E1=90=A7 > > On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault > wrote: > >> Hi Dick, >> >> In GNAP, the client isn't managing state (unlike a web app), the entire >> point is that the lifecycle should be managed by the AS. >> >> As in any state machine, there are states and transitions. Here we're no= t >> passing state, merely expressing "please continue". The client can be >> completely unaware of the underlying state. >> In effect the client only has the ability to ask the server to generate >> the next transition. >> >> So I don't think you can compare that to cookies. It's a different >> behavior. BTW if it was the case it would lead to a whole new class of >> issues, because there's an entire legal framework around cookies... >> >> To avoid confusion with a standard access token, we have the "key" field= . >> My proposal would be to make it more explicitly (cf comment in issue 67)= . >> >> Fabien >> >> >> Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt a = =C3=A9crit : >> >>> When I look at how GNAP is using access tokens for continuation >>> requests, and the pull request #129 >>> >>> >>> Those "access tokens" look a lot more like cookies (managing state) tha= n >>> how access tokens are usually used (representing authorization). See ta= ble >>> below. >>> >>> If there is a real requirement for passing state back and forth between >>> a server (the AS in this case) and the client when making API calls, th= en I >>> suggest that is out of scope for GNAP as I see it being a general purpo= se >>> mechanism for any API. >>> >>> /Dick >>> >>> >>> >>> *cookies*- issued by server being accessed >>> - are not presented to other servers >>> - issued after first access >>> - may be different for different URLs >>> - may be updated on each access >>> - represents the context of a session (state) >>> >>> >>> *access tokens*- issued by an independent service (AS) >>> - may be used at any URL at the RS >>> - new ones issued by AS as needed >>> - represents authorization granted to a client at an RS >>> =E1=90=A7 >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --000000000000409fd505b4c8b582 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the client was directly managing/= storing its state, then it would indeed effectively work as a cookie.=C2=A0=
But here the access token merely provides a map to the curre= nt state (opaque to the client), as managed/controlled by the AS.=C2=A0
=
It's a very different use case compared to what cookies are = used for in webapps.=C2=A0

Having a unique URL is = a different design (XAuth was more aligned with that idea).=C2=A0

Fabien
=C2=A0=C2=A0

On Mon, Nov 23, 2020 at = 5:09 PM Dick Hardt <dick.hardt@g= mail.com> wrote:
If all the access token is doing is expressing &qu= ot;please continue" ... why do we need an access token?

=
Why not just have a unique=C2=A0URL for the grant request? The URL is = the identifier for the grant request that allows the client to delete, upda= te, etc.

How the access token is being used is jus= t like a cookie. The AS gives a string to the client and the client must pa= ss the string back to the AS when it calls it,=C2=A0the AS may then give a = new string=C2=A0to the client for the next call. Works like a cookie. I don= 't know why you think there are legal issues around this.=C2=A0

/Dick



<= /div>
3D""=E1=90=A7

On Sun, Nov 22, 2020 at 11:40 PM Fabien= Imbault <= fabien.imbault@gmail.com> wrote:
Hi Dick,

In GNAP, the client isn't managing state (unlike a= web app), the entire point is that the lifecycle should be managed by the = AS.=C2=A0

As in any stat= e machine, there are states and transitions. Here we're not passing sta= te, merely expressing "please continue". The client can be comple= tely unaware of the underlying state.=C2=A0
In effect the client only has the ability to= ask the server to generate the next transition.

So I don't think you can compare = that to cookies. It's a different behavior. BTW if it was the case it w= ould lead to a whole new class of issues, because there's an entire leg= al framework around cookies...=C2=A0

To avoid confusion with a standard access token, we have the &= quot;key" field. My proposal would be to make it more explicitly (cf c= omment in issue 67).

Fab= ien=C2=A0


Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt <= ;dick.hardt@gmail= .com> a =C3=A9crit=C2=A0:
When I look at how GNAP is using acc= ess tokens for continuation requests, and the pull request=C2=A0#129

Those "access tokens&quo= t; look a lot more like cookies (managing state) than how access tokens are= usually used (representing authorization). See table below.

=
If there is a real requirement for passing state back and forth = between a server (the AS in this case) and the client when making API calls= , then I suggest that is out of scope for GNAP as I see it being a general= =C2=A0purpose mechanism for any API.

/Dick

cookies
- issued by server being accessed- are not presented to other servers
- issued after first access
- = may be different for different URLs
- may be updated on each access
-= represents the context of a session (state)

access tokens
- issued by an independent service (AS)
- may be used at any URL at the= RS
- new ones issued by AS as needed
- represents authorization gran= ted to a client at an RS
--000000000000409fd505b4c8b582-- From nobody Mon Nov 23 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 BC76F3A0A47 for ; Mon, 23 Nov 2020 09:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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 XvCtA2_aMK8g for ; Mon, 23 Nov 2020 09:38:36 -0800 (PST) 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 9981C3A0A3E for ; Mon, 23 Nov 2020 09:38:35 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id u18so24891578lfd.9 for ; Mon, 23 Nov 2020 09:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8+6/MhWY/tDPBckfr0g3gXdiHvgNBiBOzBqbwP3juoo=; b=kg1UFR9QA9NcqSuCEqTjijY/AMsJleVR8hyXxkGoj9lkh50UfukpSZHjPDyiZS1KWl tbI3r76lc8WLCUJu4IEJSrNWhEwmszDqTmP+jSULmob0akNcUF30PwhHCfRhxxo2fDJB hi4ufGm5m3wwSiJFSeA+Pu6k97Xw8i4g7qFPbS43R7k1iNsEqvioqOGn02KCOhPVhF2D 07ale6YyPbfd8qyJkK28gcnGgp0x5w9ClXABVcO+0+HnbGyEV16+nOzItA2YemBmUKIi d9+/xLDtEXrYf5j4VfQRR4G6njS1NABME72ZDDiaheSHo3Qi0gCetumrUWf1sDpRK7NP nMTw== 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=8+6/MhWY/tDPBckfr0g3gXdiHvgNBiBOzBqbwP3juoo=; b=ZRW/QM5WpRNhYL5BO5c2q64oCNLTMQpcGoX5sb7EPinF1sLszKWwBfPSv/KZrDfLR0 YmgzHIlfD/2LeNnaoxLixupJAgFMlZVClvefTgP7RuOvVLl9PPrwRxtsjanaRtm8RQZf MRouXLjSOV8VYDqyAqV6k8EKQqWrrhEVym5jtNzELDcxMr7UyY6B8SrZXQPTCYhOCkzZ Mf52yZFh7VfJ3f6GFqh60xo3Q0d2IR2uZI+5dWj+AK/OtuSwqVILCSlVanU4UOa61vhd dP7C4GM+VJm/OL5Veb9miFGa7ShdwKap5tALfnknfhYc0ZxfGqzavqihL/POjNH/ccN5 X2tw== X-Gm-Message-State: AOAM530nzQw2e3eSbeTqhIWAabWmL/bP+9ab2GLX7G4rQNCvcKCmxGJN anwGh9bjbafT2dvx+MQvdAkJhviSfQpRiCGnm9E= X-Google-Smtp-Source: ABdhPJxj8NAIWpv0IGzlEqby+0HR/m+xXeH6jMs7nZvQny7yCeh5mEAIAM+fAeuYw+T/4SKHCqAwVWom/yZb0ZxfIf4= X-Received: by 2002:a19:88a:: with SMTP id 132mr123079lfi.316.1606153113657; Mon, 23 Nov 2020 09:38:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 23 Nov 2020 09:37:56 -0800 Message-ID: To: Fabien Imbault Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000cb63bd05b4c9a927" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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: Mon, 23 Nov 2020 17:38:39 -0000 --000000000000cb63bd05b4c9a927 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To clarify, I am talking about HTTP cookies, which are effectively opaque to the web browser, and used by the web server to store state. https://en.wikipedia.org/wiki/HTTP_cookie A client may use local storage for saving state, but that is completely different from an HTTP cookie which is issued by the server. =E1=90=A7 On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault wrote: > If the client was directly managing/storing its state, then it would > indeed effectively work as a cookie. > But here the access token merely provides a map to the current state > (opaque to the client), as managed/controlled by the AS. > It's a very different use case compared to what cookies are used for in > webapps. > > Having a unique URL is a different design (XAuth was more aligned with > that idea). > > Fabien > > > On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt wrote: > >> If all the access token is doing is expressing "please continue" ... why >> do we need an access token? >> >> Why not just have a unique URL for the grant request? The URL is the >> identifier for the grant request that allows the client to delete, updat= e, >> etc. >> >> How the access token is being used is just like a cookie. The AS gives a >> string to the client and the client must pass the string back to the AS >> when it calls it, the AS may then give a new string to the client for th= e >> next call. Works like a cookie. I don't know why you think there are leg= al >> issues around this. >> >> /Dick >> >> >> >> =E1=90=A7 >> >> On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault >> wrote: >> >>> Hi Dick, >>> >>> In GNAP, the client isn't managing state (unlike a web app), the entire >>> point is that the lifecycle should be managed by the AS. >>> >>> As in any state machine, there are states and transitions. Here we're >>> not passing state, merely expressing "please continue". The client can = be >>> completely unaware of the underlying state. >>> In effect the client only has the ability to ask the server to generate >>> the next transition. >>> >>> So I don't think you can compare that to cookies. It's a different >>> behavior. BTW if it was the case it would lead to a whole new class of >>> issues, because there's an entire legal framework around cookies... >>> >>> To avoid confusion with a standard access token, we have the "key" >>> field. My proposal would be to make it more explicitly (cf comment in i= ssue >>> 67). >>> >>> Fabien >>> >>> >>> Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt a >>> =C3=A9crit : >>> >>>> When I look at how GNAP is using access tokens for continuation >>>> requests, and the pull request #129 >>>> >>>> >>>> Those "access tokens" look a lot more like cookies (managing state) >>>> than how access tokens are usually used (representing authorization). = See >>>> table below. >>>> >>>> If there is a real requirement for passing state back and forth betwee= n >>>> a server (the AS in this case) and the client when making API calls, t= hen I >>>> suggest that is out of scope for GNAP as I see it being a general purp= ose >>>> mechanism for any API. >>>> >>>> /Dick >>>> >>>> >>>> >>>> *cookies*- issued by server being accessed >>>> - are not presented to other servers >>>> - issued after first access >>>> - may be different for different URLs >>>> - may be updated on each access >>>> - represents the context of a session (state) >>>> >>>> >>>> *access tokens*- issued by an independent service (AS) >>>> - may be used at any URL at the RS >>>> - new ones issued by AS as needed >>>> - represents authorization granted to a client at an RS >>>> =E1=90=A7 >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --000000000000cb63bd05b4c9a927 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A client may use local storage for saving=C2=A0state, but= that is completely different from an HTTP cookie which is issued by the se= rver.
=E1=90=A7

On Mon, Nov 23, 2020 at 8:30 AM F= abien Imbault <fabien.imbaul= t@gmail.com> wrote:
If the client was directl= y managing/storing its state, then it would indeed effectively work as a co= okie.=C2=A0
But here the access token merely provides a map t= o the current state (opaque to the client), as managed/controlled by the AS= .=C2=A0
It's a very different use case compared to what c= ookies are used for in webapps.=C2=A0

Having a uni= que URL is a different design (XAuth was more aligned with that idea).=C2= =A0

Fabien
=C2=A0=C2=A0

<= div class=3D"gmail_quote">
On Mon, Nov= 23, 2020 at 5:09 PM Dick Hardt <dick.hardt@gmail.com> wrote:
If all the access t= oken is doing is expressing "please continue" ... why do we need = an access token?

Why not just have a unique=C2=A0URL for= the grant request? The URL is the identifier for the grant request that al= lows the client to delete, update, etc.

How the ac= cess token is being used is just like a cookie. The AS gives a string to th= e client and the client must pass the string back to the AS when it calls i= t,=C2=A0the AS may then give a new string=C2=A0to the client for the next c= all. Works like a cookie. I don't know why you think there are legal is= sues around this.=C2=A0

/Dick

=


3D""=E1=90=A7
On Sun, = Nov 22, 2020 at 11:40 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
<= /div>
Hi= Dick,

In GNAP, the client isn= 't managing state (unlike a web app), the entire point is that the life= cycle should be managed by the AS.=C2=A0

<= div dir=3D"auto">As in any state machine, there are states and transitions.= Here we're not passing state, merely expressing "please continue&= quot;. The client can be completely unaware of the underlying state.=C2=A0<= /div>
In effect the= client only has the ability to ask the server to generate the next transit= ion.

So I don= 't think you can compare that to cookies. It's a different behavior= . BTW if it was the case it would lead to a whole new class of issues, beca= use there's an entire legal framework around cookies...=C2=A0

To avoid confusion with a standar= d access token, we have the "key" field. My proposal would be to = make it more explicitly (cf comment in issue 67).
Fabien=C2=A0


Le lun. 23 nov. 2020= =C3=A0 02:06, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
When I = look at how GNAP is using access tokens for continuation requests, and the = pull request=C2=A0#129

= Those "access tokens" look a lot more like cookies (managing stat= e) than how access tokens are usually used (representing authorization). Se= e table below.

If there is a real requirement for = passing state back and forth between a server (the AS in this case) and the= client when making API calls, then I suggest that is out of scope for GNAP= as I see it being a general=C2=A0purpose mechanism for any API.
=
/Dick


cookies
- issue= d by server being accessed
- are not presented to other servers
- iss= ued after first access
- may be different for different URLs
- may be= updated on each access
- represents the context of a session (state)
access tokens
- issued by an independent service (AS)
- m= ay be used at any URL at the RS
- new ones issued by AS as needed
- r= epresents authorization granted to a client at an RS
3D""=E1=90=A7
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--000000000000cb63bd05b4c9a927-- From nobody Mon Nov 23 09:45: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 2FACA3A0B87 for ; Mon, 23 Nov 2020 09:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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 ydhRO_bUSJgQ for ; Mon, 23 Nov 2020 09:45:00 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0: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 4E83D3A0B0E for ; Mon, 23 Nov 2020 09:45:00 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id b8so1210076ila.13 for ; Mon, 23 Nov 2020 09:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5LOeJ6l8jv7BWEYwI7ahvZ1pvOSK5UIGLO2ntm4yOhI=; b=cCLHz1zfQYeWST/b2DZ44GN/oGwRhpUhjR6emgCp8f81tsPr0rtcDjX2vW92nO0xfa cFojBnt/XYrc3SYV53hWjCpy7fVWnk/CsUzPKbs8GNrf2lzFN+Jglo2xvRPzaAlBU/nf uyPLQKmSVYfM5k2YO2K+VhE5L+m+rZAjc8I9uJg1vXly9lLsHWs8e/AfcWTHLKcQxsYb 8n3oGiIHgdQthWCiPhjGGRoQ2Nj8LCfa8THThFjyUiISYC5RUYWZOIowSU+0Pw25B2OD Nz99REx4n/vepYLgmRG/xL3sWnfqXn2Lgnh0s1Grd3pWGvtbWhkg/cl2n/DZ2V2t+VaG geGw== 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=5LOeJ6l8jv7BWEYwI7ahvZ1pvOSK5UIGLO2ntm4yOhI=; b=aTuLjp70bleQi99R2pRvSVhpStl4sz842KvwdvQnBw2KYysjJgUQMff+OW/dFeC3ZL DIog0zU+yKW4c8NwRxfaHqWYzWOT0v/5I5kEcyj2SU31GmqkWzfid4Gnx/NroUAvBlo/ IBnq+kkV0OFYCuULpV85vAz7g7fWyVJchv3hG9lKNPb6WaZkjECpUcfYc55RY6Njf6UN fNgq5xM5QEDButsx9z7aKPk1CYejLZUu9LHmp1Z16O0PubytBIMg/ucGmj3ER/6LYEv/ QB/JxFQGRaK6WNbjibVxTJUXJljtCNYicxU7/+/tbXzUuYT2DlUDY34BGV84xfTcdgFP K2Tw== X-Gm-Message-State: AOAM533LtAx7/d1tMfg0rGb0uYQ5/hneqOXJLjNZ/8irFCLG86ZrpdEg GxxU+kKh39aSawIHOYxUhw0j3MFJeziPUBR4QxY= X-Google-Smtp-Source: ABdhPJy4FfF/0XWmpLKjm68mJzTXOWjcVPere8lk2L7TyGNYjlbXscwsjBmPXq96G5oEPPzY3+bKuGQGqdxt151Kn10= X-Received: by 2002:a92:d489:: with SMTP id p9mr754859ilg.123.1606153499414; Mon, 23 Nov 2020 09:44:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 23 Nov 2020 18:44:47 +0100 Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000c9974a05b4c9c007" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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: Mon, 23 Nov 2020 17:45:02 -0000 --000000000000c9974a05b4c9c007 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes. "Cookies were designed to be a reliable mechanism for websites to remember stateful information= ". We're not storing anything, it's just a reference. On Mon, Nov 23, 2020 at 6:38 PM Dick Hardt wrote: > To clarify, I am talking about HTTP cookies, which are effectively opaque > to the web browser, and used by the web server to store state. > > https://en.wikipedia.org/wiki/HTTP_cookie > > A client may use local storage for saving state, but that is completely > different from an HTTP cookie which is issued by the server. > =E1=90=A7 > > On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault > wrote: > >> If the client was directly managing/storing its state, then it would >> indeed effectively work as a cookie. >> But here the access token merely provides a map to the current state >> (opaque to the client), as managed/controlled by the AS. >> It's a very different use case compared to what cookies are used for in >> webapps. >> >> Having a unique URL is a different design (XAuth was more aligned with >> that idea). >> >> Fabien >> >> >> On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt wrote: >> >>> If all the access token is doing is expressing "please continue" ... wh= y >>> do we need an access token? >>> >>> Why not just have a unique URL for the grant request? The URL is the >>> identifier for the grant request that allows the client to delete, upda= te, >>> etc. >>> >>> How the access token is being used is just like a cookie. The AS gives = a >>> string to the client and the client must pass the string back to the AS >>> when it calls it, the AS may then give a new string to the client for t= he >>> next call. Works like a cookie. I don't know why you think there are le= gal >>> issues around this. >>> >>> /Dick >>> >>> >>> >>> =E1=90=A7 >>> >>> On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >>>> Hi Dick, >>>> >>>> In GNAP, the client isn't managing state (unlike a web app), the entir= e >>>> point is that the lifecycle should be managed by the AS. >>>> >>>> As in any state machine, there are states and transitions. Here we're >>>> not passing state, merely expressing "please continue". The client can= be >>>> completely unaware of the underlying state. >>>> In effect the client only has the ability to ask the server to generat= e >>>> the next transition. >>>> >>>> So I don't think you can compare that to cookies. It's a different >>>> behavior. BTW if it was the case it would lead to a whole new class of >>>> issues, because there's an entire legal framework around cookies... >>>> >>>> To avoid confusion with a standard access token, we have the "key" >>>> field. My proposal would be to make it more explicitly (cf comment in = issue >>>> 67). >>>> >>>> Fabien >>>> >>>> >>>> Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt a >>>> =C3=A9crit : >>>> >>>>> When I look at how GNAP is using access tokens for continuation >>>>> requests, and the pull request #129 >>>>> >>>>> >>>>> Those "access tokens" look a lot more like cookies (managing state) >>>>> than how access tokens are usually used (representing authorization).= See >>>>> table below. >>>>> >>>>> If there is a real requirement for passing state back and forth >>>>> between a server (the AS in this case) and the client when making API >>>>> calls, then I suggest that is out of scope for GNAP as I see it being= a >>>>> general purpose mechanism for any API. >>>>> >>>>> /Dick >>>>> >>>>> >>>>> >>>>> *cookies*- issued by server being accessed >>>>> - are not presented to other servers >>>>> - issued after first access >>>>> - may be different for different URLs >>>>> - may be updated on each access >>>>> - represents the context of a session (state) >>>>> >>>>> >>>>> *access tokens*- issued by an independent service (AS) >>>>> - may be used at any URL at the RS >>>>> - new ones issued by AS as needed >>>>> - represents authorization granted to a client at an RS >>>>> =E1=90=A7 >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> --000000000000c9974a05b4c9c007 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes. "Cookies were designed to be a reliable mechanism= for websites to remember=C2=A0stateful=C2=A0information". We're not storing an= ything, it's just a reference.=C2=A0

On Mon, Nov 23, 2020 at 6:38= PM Dick Hardt <dick.hardt@gmail= .com> wrote:
To clarify, I am talking about HTTP cookies, whic= h are effectively opaque to the web browser,=C2=A0and used by the web serve= r to store state.


A client may use local storage for = saving=C2=A0state, but that is completely different from an HTTP cookie whi= ch is issued by the server.
3D""=E1=90=A7
On Mo= n, Nov 23, 2020 at 8:30 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
<= div dir=3D"ltr">
If the client was directly managing/storing its state,= then it would indeed effectively work as a cookie.=C2=A0
But= here the access token merely provides a map to the current state (opaque t= o the client), as managed/controlled by the AS.=C2=A0
It'= s a very different use case compared to what cookies are used for in webapp= s.=C2=A0

Having a unique URL is a different design= (XAuth was more aligned with that idea).=C2=A0

Fa= bien
=C2=A0=C2=A0

On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt= <dick.hardt@g= mail.com> wrote:
If all the access token is doing is expressing &qu= ot;please continue" ... why do we need an access token?

=
Why not just have a unique=C2=A0URL for the grant request? The URL is = the identifier for the grant request that allows the client to delete, upda= te, etc.

How the access token is being used is jus= t like a cookie. The AS gives a string to the client and the client must pa= ss the string back to the AS when it calls it,=C2=A0the AS may then give a = new string=C2=A0to the client for the next call. Works like a cookie. I don= 't know why you think there are legal issues around this.=C2=A0

/Dick



<= /div>
3D""=E1=90=A7

On Sun, Nov 22, 2020 at 11:40 PM Fabien= Imbault <= fabien.imbault@gmail.com> wrote:
Hi Dick,

In GNAP, the client isn't managing state (unlike a= web app), the entire point is that the lifecycle should be managed by the = AS.=C2=A0

As in any stat= e machine, there are states and transitions. Here we're not passing sta= te, merely expressing "please continue". The client can be comple= tely unaware of the underlying state.=C2=A0
In effect the client only has the ability to= ask the server to generate the next transition.

So I don't think you can compare = that to cookies. It's a different behavior. BTW if it was the case it w= ould lead to a whole new class of issues, because there's an entire leg= al framework around cookies...=C2=A0

To avoid confusion with a standard access token, we have the &= quot;key" field. My proposal would be to make it more explicitly (cf c= omment in issue 67).

Fab= ien=C2=A0


Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt <= ;dick.hardt@gmail= .com> a =C3=A9crit=C2=A0:
When I look at how GNAP is using acc= ess tokens for continuation requests, and the pull request=C2=A0#129

Those "access tokens&quo= t; look a lot more like cookies (managing state) than how access tokens are= usually used (representing authorization). See table below.

=
If there is a real requirement for passing state back and forth = between a server (the AS in this case) and the client when making API calls= , then I suggest that is out of scope for GNAP as I see it being a general= =C2=A0purpose mechanism for any API.

/Dick

cookies
- issued by server being accessed- are not presented to other servers
- issued after first access
- = may be different for different URLs
- may be updated on each access
-= represents the context of a session (state)

access tokens
- issued by an independent service (AS)
- may be used at any URL at the= RS
- new ones issued by AS as needed
- represents authorization gran= ted to a client at an RS
--000000000000c9974a05b4c9c007-- From nobody Mon Nov 23 09:52: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 DB8313A0B98 for ; Mon, 23 Nov 2020 09:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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 vvYN7meGHkoa for ; Mon, 23 Nov 2020 09:51:56 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D503A0B95 for ; Mon, 23 Nov 2020 09:51:56 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id e139so25020800lfd.1 for ; Mon, 23 Nov 2020 09:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MmqY/fMSLuaQnHvAQxa+iRI+I65bBs/Go2tjTagGMR0=; b=bJw8DY7j2DuW8dHi3MC38iKYjf+eEoMkDvk6KiN7/UfThxldRxcSLMhs12P4d22mid PIYxRu6MWH91gYtPY3ZThWZSJcgEoQH3GskKHh86Q4Gn+/SLyNfX2sUOLjN+/uDjJXeM Xu2hxIRkSrveRuO79xPpOLaLOGOQzTEQeoAmBWwGbx89ileCNaX3XX6RX6omeFNdrXsT a1T35vxdbsg+MaUXNzUleDIARPsAuq8wYumPcQxl4m2alF1HVQW7cd5oYmv0mLATx6S0 bz5DQp9wB0iVBvhWUZQZTXzKvtZYmniQFcKc8P+suCuQqPTjQwzGOHbBiWtZCMNpkpZT FbnA== 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=MmqY/fMSLuaQnHvAQxa+iRI+I65bBs/Go2tjTagGMR0=; b=T7X1Lqt3mw/S7fSCIl/76PFp1amB4n6OaZjNnAKfe6HNNq+t120eq3VG+j0P5cxVLG w5o+I0Mmokv+jUnfTa3bcBb1xn5sSu3qipzHfYDxeGLLM2awbAWruZN+19iKiS/qRqOG C/9wTabzmVklD74hv4h5jASVERALoT8rG2Zdzd2koAU5I6oc/mcvVc02X9T5x0+slvL6 aB7RPatBNQRoDxiSL5E39jdS8IlBBzXvsK4Ry6ibtzdYWFVFNvMAZB3byLZ3CumU0jAV R1f6dXt01QT+CNWI56BDvuPFC5XcB5xAesqCPbprJ1RpkPVNXzAAjA9nz4qpJXkLXM0l 857A== X-Gm-Message-State: AOAM530UCNwpgmJoTqn9HhXT+8PiLK02ASO8ZkcEcCU2BN29/RhVNd2o FQmi9XW3/IoUOeqh/UZ2LmSBtDfyPuXfVll7r8I= X-Google-Smtp-Source: ABdhPJyIDmPldEzMY3VaAn8O99rE3X4oxCJQfh28iK0mi8qrR+GVdQBvyYX18McDdEb03m1APdsh+MNkjSyMzunBLsQ= X-Received: by 2002:ac2:4156:: with SMTP id c22mr111279lfi.221.1606153914332; Mon, 23 Nov 2020 09:51:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 23 Nov 2020 09:51:18 -0800 Message-ID: To: Fabien Imbault Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000084ba3a05b4c9d907" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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: Mon, 23 Nov 2020 17:51:59 -0000 --00000000000084ba3a05b4c9d907 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If it is an access token, it may be a reference, but is more likely state, and in the WG people talked about how the server could be stateless as all state would be in the access token. In this thread, it looked like people were thinking it would store state: https://mailarchive.ietf.org/arch/msg/txauth/xPVdY74mytf83xLeyCGyoaV-gK8/ If it is just a reference, then it is an identifier, and then why not just use a URL? The motivation for it to be an access token seemed to be to store state. /Dick =E1=90=A7 On Mon, Nov 23, 2020 at 9:45 AM Fabien Imbault wrote: > Yes. "Cookies were designed to be a reliable mechanism for websites to > remember stateful informati= on". > We're not storing anything, it's just a reference. > > On Mon, Nov 23, 2020 at 6:38 PM Dick Hardt wrote: > >> To clarify, I am talking about HTTP cookies, which are effectively opaqu= e >> to the web browser, and used by the web server to store state. >> >> https://en.wikipedia.org/wiki/HTTP_cookie >> >> A client may use local storage for saving state, but that is completely >> different from an HTTP cookie which is issued by the server. >> =E1=90=A7 >> >> On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault >> wrote: >> >>> If the client was directly managing/storing its state, then it would >>> indeed effectively work as a cookie. >>> But here the access token merely provides a map to the current state >>> (opaque to the client), as managed/controlled by the AS. >>> It's a very different use case compared to what cookies are used for in >>> webapps. >>> >>> Having a unique URL is a different design (XAuth was more aligned with >>> that idea). >>> >>> Fabien >>> >>> >>> On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt wrote= : >>> >>>> If all the access token is doing is expressing "please continue" ... >>>> why do we need an access token? >>>> >>>> Why not just have a unique URL for the grant request? The URL is the >>>> identifier for the grant request that allows the client to delete, upd= ate, >>>> etc. >>>> >>>> How the access token is being used is just like a cookie. The AS gives >>>> a string to the client and the client must pass the string back to the= AS >>>> when it calls it, the AS may then give a new string to the client for = the >>>> next call. Works like a cookie. I don't know why you think there are l= egal >>>> issues around this. >>>> >>>> /Dick >>>> >>>> >>>> >>>> =E1=90=A7 >>>> >>>> On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Dick, >>>>> >>>>> In GNAP, the client isn't managing state (unlike a web app), the >>>>> entire point is that the lifecycle should be managed by the AS. >>>>> >>>>> As in any state machine, there are states and transitions. Here we're >>>>> not passing state, merely expressing "please continue". The client ca= n be >>>>> completely unaware of the underlying state. >>>>> In effect the client only has the ability to ask the server to >>>>> generate the next transition. >>>>> >>>>> So I don't think you can compare that to cookies. It's a different >>>>> behavior. BTW if it was the case it would lead to a whole new class o= f >>>>> issues, because there's an entire legal framework around cookies... >>>>> >>>>> To avoid confusion with a standard access token, we have the "key" >>>>> field. My proposal would be to make it more explicitly (cf comment in= issue >>>>> 67). >>>>> >>>>> Fabien >>>>> >>>>> >>>>> Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt = a >>>>> =C3=A9crit : >>>>> >>>>>> When I look at how GNAP is using access tokens for continuation >>>>>> requests, and the pull request #129 >>>>>> >>>>>> >>>>>> Those "access tokens" look a lot more like cookies (managing state) >>>>>> than how access tokens are usually used (representing authorization)= . See >>>>>> table below. >>>>>> >>>>>> If there is a real requirement for passing state back and forth >>>>>> between a server (the AS in this case) and the client when making AP= I >>>>>> calls, then I suggest that is out of scope for GNAP as I see it bein= g a >>>>>> general purpose mechanism for any API. >>>>>> >>>>>> /Dick >>>>>> >>>>>> >>>>>> >>>>>> *cookies*- issued by server being accessed >>>>>> - are not presented to other servers >>>>>> - issued after first access >>>>>> - may be different for different URLs >>>>>> - may be updated on each access >>>>>> - represents the context of a session (state) >>>>>> >>>>>> >>>>>> *access tokens*- issued by an independent service (AS) >>>>>> - may be used at any URL at the RS >>>>>> - new ones issued by AS as needed >>>>>> - represents authorization granted to a client at an RS >>>>>> =E1=90=A7 >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> --00000000000084ba3a05b4c9d907 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
3D""=E1=90=A7

On Mon, Nov 23, 2020 at 9:45 = AM Fabien Imbault <fabien.im= bault@gmail.com> wrote:
Yes. "Cookies were designed to be a rel= iable mechanism for websites to remember=C2=A0stateful=C2=A0information". We're not stori= ng anything, it's just a reference.=C2=A0

On Mon, Nov 23, 2020 at= 6:38 PM Dick Hardt <dick.hardt@gmail.com> wrote:
To clarify, I am talking a= bout HTTP cookies, which are effectively opaque to the web browser,=C2=A0an= d used by the web server to store state.


A client m= ay use local storage for saving=C2=A0state, but that is completely differen= t from an HTTP cookie which is issued by the server.
3D""=E1=90=A7

On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault <fabien.imbault@gm= ail.com> wrote:
If the client was directly ma= naging/storing its state, then it would indeed effectively work as a cookie= .=C2=A0
But here the access token merely provides a map to th= e current state (opaque to the client), as managed/controlled by the AS.=C2= =A0
It's a very different use case compared to what cooki= es are used for in webapps.=C2=A0

Having a unique = URL is a different design (XAuth was more aligned with that idea).=C2=A0

Fabien
=C2=A0=C2=A0

On Mon, Nov 23, 2= 020 at 5:09 PM Dick Hardt <dick.hardt@gmail.com> wrote:
If all the access token i= s doing is expressing "please continue" ... why do we need an acc= ess token?

Why not just have a unique=C2=A0URL for the g= rant request? The URL is the identifier for the grant request that allows t= he client to delete, update, etc.

How the access t= oken is being used is just like a cookie. The AS gives a string to the clie= nt and the client must pass the string back to the AS when it calls it,=C2= =A0the AS may then give a new string=C2=A0to the client for the next call. = Works like a cookie. I don't know why you think there are legal issues = around this.=C2=A0

/Dick

=

3D""=E1=90=A7

On Sun, Nov 2= 2, 2020 at 11:40 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
=
Hi Dick= ,

In GNAP, the client isn'= t managing state (unlike a web app), the entire point is that the lifecycle= should be managed by the AS.=C2=A0

As in any state machine, there are states and transitions. Here= we're not passing state, merely expressing "please continue"= . The client can be completely unaware of the underlying state.=C2=A0
=
In effect the clie= nt only has the ability to ask the server to generate the next transition.<= /span>

So I don'= t think you can compare that to cookies. It's a different behavior. BTW= if it was the case it would lead to a whole new class of issues, because t= here's an entire legal framework around cookies...=C2=A0

To avoid confusion with a standard ac= cess token, we have the "key" field. My proposal would be to make= it more explicitly (cf comment in issue 67).

Fabien=C2=A0


Le lun. 23 nov. 2020 =C3= =A0 02:06, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
When I look= at how GNAP is using access tokens for continuation requests, and the pull= request=C2=A0#129

Thos= e "access tokens" look a lot more like cookies (managing state) t= han how access tokens are usually used (representing authorization). See ta= ble below.

If there is a real requirement for pass= ing state back and forth between a server (the AS in this case) and the cli= ent when making API calls, then I suggest that is out of scope for GNAP as = I see it being a general=C2=A0purpose mechanism for any API.

=
/Dick


cookies
- issued by= server being accessed
- are not presented to other servers
- issued = after first access
- may be different for different URLs
- may be upd= ated on each access
- represents the context of a session (state)
access tokens
- issued by an independent service (AS)
- may b= e used at any URL at the RS
- new ones issued by AS as needed
- repre= sents authorization granted to a client at an RS
3D""=E1=90=A7
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--00000000000084ba3a05b4c9d907-- From nobody Mon Nov 23 09:55: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 A6F6C3A0BB3 for ; Mon, 23 Nov 2020 09:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.017 X-Spam-Level: X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 C1RYnnLFfIhR for ; Mon, 23 Nov 2020 09:55:07 -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 5F9653A0BAD for ; Mon, 23 Nov 2020 09:55:06 -0800 (PST) Received: from [192.168.1.19] (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 0ANHt4Uw029230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Nov 2020 12:55:04 -0500 From: Justin Richer Message-Id: <9D3D60CC-5019-4CC2-BE2D-4EF789FABE31@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_2811B813-EBC3-477D-A0E3-701254860F31" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 23 Nov 2020 12:55:04 -0500 In-Reply-To: Cc: Dick Hardt , GNAP Mailing List To: Fabien Imbault References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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: Mon, 23 Nov 2020 17:55:12 -0000 --Apple-Mail=_2811B813-EBC3-477D-A0E3-701254860F31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 An important distinction here is that the access tokens in question are = always going to be bound to a key for presentation purposes, so in many = ways they are quite distinct from cookies. Since =E2=80=9Ccontinuation=E2=80=9D in its various forms is now an API, = why not treat it like other APIs the client would call and use access = tokens? Apart from design choices, what is the negative cost of requiring an = access token? We aren=E2=80=99t asking the client to do anything it=E2=80=99s not = already doing. Even if the client is going to use bearer tokens at a = downstream RS, the signature presentation mechanism for the bound access = token at the continuation API is exactly the same as what the client = used in the first place to get the continuation response.=20 We aren=E2=80=99t asking the AS to do anything special either since it = already needs to be able to validate the signature inbound, and it needs = to be able to reference an artifact for the ongoing request (stateful or = not).=20 =E2=80=94 Justin > On Nov 23, 2020, at 12:44 PM, Fabien Imbault = wrote: >=20 > Yes. "Cookies were designed to be a reliable mechanism for websites to = remember stateful = information". We're not storing anything, it's just a reference.=20 >=20 > On Mon, Nov 23, 2020 at 6:38 PM Dick Hardt > wrote: > To clarify, I am talking about HTTP cookies, which are effectively = opaque to the web browser, and used by the web server to store state. >=20 > https://en.wikipedia.org/wiki/HTTP_cookie = >=20 > A client may use local storage for saving state, but that is = completely different from an HTTP cookie which is issued by the server. > =E1=90=A7 >=20 > On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault = > wrote: > If the client was directly managing/storing its state, then it would = indeed effectively work as a cookie.=20 > But here the access token merely provides a map to the current state = (opaque to the client), as managed/controlled by the AS.=20 > It's a very different use case compared to what cookies are used for = in webapps.=20 >=20 > Having a unique URL is a different design (XAuth was more aligned with = that idea).=20 >=20 > Fabien > =20 >=20 > On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt > wrote: > If all the access token is doing is expressing "please continue" ... = why do we need an access token? >=20 > Why not just have a unique URL for the grant request? The URL is the = identifier for the grant request that allows the client to delete, = update, etc. >=20 > How the access token is being used is just like a cookie. The AS gives = a string to the client and the client must pass the string back to the = AS when it calls it, the AS may then give a new string to the client for = the next call. Works like a cookie. I don't know why you think there are = legal issues around this.=20 >=20 > /Dick >=20 >=20 >=20 > =E1=90=A7 >=20 > On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault = > wrote: > Hi Dick, >=20 > In GNAP, the client isn't managing state (unlike a web app), the = entire point is that the lifecycle should be managed by the AS.=20 >=20 > As in any state machine, there are states and transitions. Here we're = not passing state, merely expressing "please continue". The client can = be completely unaware of the underlying state.=20 > In effect the client only has the ability to ask the server to = generate the next transition. >=20 > So I don't think you can compare that to cookies. It's a different = behavior. BTW if it was the case it would lead to a whole new class of = issues, because there's an entire legal framework around cookies...=20 >=20 > To avoid confusion with a standard access token, we have the "key" = field. My proposal would be to make it more explicitly (cf comment in = issue 67). >=20 > Fabien=20 >=20 >=20 > Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt > a =C3=A9crit : > When I look at how GNAP is using access tokens for continuation = requests, and the pull request #129 = >=20 > Those "access tokens" look a lot more like cookies (managing state) = than how access tokens are usually used (representing authorization). = See table below. >=20 > If there is a real requirement for passing state back and forth = between a server (the AS in this case) and the client when making API = calls, then I suggest that is out of scope for GNAP as I see it being a = general purpose mechanism for any API. >=20 > /Dick >=20 >=20 > cookies > - issued by server being accessed > - are not presented to other servers > - issued after first access > - may be different for different URLs > - may be updated on each access > - represents the context of a session (state) >=20 > access tokens > - issued by an independent service (AS) > - may be used at any URL at the RS > - new ones issued by AS as needed > - represents authorization granted to a client at an RS > =E1=90=A7 > --=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=_2811B813-EBC3-477D-A0E3-701254860F31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
An important distinction here is that the access tokens in = question are always going to be bound to a key for presentation = purposes, so in many ways they are quite distinct from = cookies.

Since = =E2=80=9Ccontinuation=E2=80=9D in its various forms is now an API, why = not treat it like other APIs the client would call and use access = tokens?

Apart = from design choices, what is the negative cost of requiring an access = token?

We = aren=E2=80=99t asking the client to do anything it=E2=80=99s not already = doing. Even if the client is going to use bearer tokens at a downstream = RS, the signature presentation mechanism for the bound access token at = the continuation API is exactly the same as what the client used in the = first place to get the continuation response. 

We aren=E2=80=99t asking = the AS to do anything special either since it already needs to be able = to validate the signature inbound, and it needs to be able to reference = an artifact for the ongoing request (stateful or not). 

 =E2=80=94 = Justin

On Nov 23, 2020, at 12:44 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Yes. "Cookies were designed to be a reliable mechanism for websites = to remember stateful information". We're not storing anything, it's just a = reference. 

On Mon, Nov = 23, 2020 at 6:38 PM Dick Hardt <dick.hardt@gmail.com> wrote:
To clarify, I am talking about HTTP cookies, which are = effectively opaque to the web browser, and used by the web server = to store state.

https://en.wikipedia.org/wiki/HTTP_cookie

A = client may use local storage for saving state, but that is = completely different from an HTTP cookie which is issued by the = server.
3D""=E1=90=A7

On Mon, Nov = 23, 2020 at 8:30 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
If the client was directly = managing/storing its state, then it would indeed effectively work as a = cookie. 
But here the access = token merely provides a map to the current state (opaque to the client), = as managed/controlled by the AS. 
It's a very different use case compared to what cookies are = used for in webapps. 

Having a unique URL is a different design (XAuth was more = aligned with that idea). 

Fabien
  

On Mon, Nov = 23, 2020 at 5:09 PM Dick Hardt <dick.hardt@gmail.com> wrote:
If all = the access token is doing is expressing "please continue" ... why do we = need an access token?

Why not just have a unique URL for the grant request? = The URL is the identifier for the grant request that allows the client = to delete, update, etc.

How the access token is being used is just like a cookie. The = AS gives a string to the client and the client must pass the string back = to the AS when it calls it, the AS may then give a new = string to the client for the next call. Works like a cookie. I = don't know why you think there are legal issues around = this. 

/Dick



3D""=E1=90=A7

On Sun, Nov = 22, 2020 at 11:40 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi = Dick,

In GNAP, the client isn't managing state (unlike a web app), = the entire point is that the lifecycle should be managed by the = AS. 

As in any state machine, there are states and = transitions. Here we're not passing state, merely expressing "please = continue". The client can be completely unaware of the underlying = state. 
In effect the client only = has the ability to ask the server to generate the next = transition.

So I don't think you can = compare that to cookies. It's a different behavior. BTW if it was the = case it would lead to a whole new class of issues, because there's an = entire legal framework around cookies... 

To avoid = confusion with a standard access token, we have the "key" field. My = proposal would be to make it more explicitly (cf comment in issue = 67).

Fabien 


Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt = <dick.hardt@gmail.com> a =C3=A9crit :
When I look at how GNAP is using access tokens for = continuation requests, and the pull request #129

Those "access tokens" look a lot more = like cookies (managing state) than how access tokens are usually used = (representing authorization). See table below.

If there is a real requirement for = passing state back and forth between a server (the AS in this case) and = the client when making API calls, then I suggest that is out of scope = for GNAP as I see it being a general purpose mechanism for any = API.

/Dick


cookies
-= issued by server being accessed
- are not presented to = other servers
- issued after first access
- = may be different for different URLs
- may be updated on = each access
- represents the context of a session = (state)

access tokens
- issued by an independent service (AS)
- = may be used at any URL at the RS
- new ones issued by AS = as needed
- represents authorization granted to a client = at an RS
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

= --Apple-Mail=_2811B813-EBC3-477D-A0E3-701254860F31-- From nobody Mon Nov 23 20:56: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 A98573A0A9A for ; Mon, 23 Nov 2020 20:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=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 0ETLAXIh_jGZ for ; Mon, 23 Nov 2020 20:56:03 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FFC3A0A97 for ; Mon, 23 Nov 2020 20:56:03 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id z14so16324765ilm.10 for ; Mon, 23 Nov 2020 20:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TQA66fd+/+23E6icpgeugowUJP9ocgb/+A/k4rgePY0=; b=rdyIxDEU6sPo2g8Mh5RF742kGG3iph849AaHr9gtsveC8Z4UrX6OSDGAFTEzVIxX6X DrY7MpkRGmVy3Eh/A1JEyg5B6Wwt5s2irf7StSNs5xfTmRCboGH5OCcABBbndvBgT0fP 7ThLuDy8h5a9qztOTegBJ3AmRDT1RSYsx8H6sxOnP0qFSkoMFNfeJLSgXUCOS832hbTC IYt1BR0B0lPDnIWip4X4l8RX4bLKbCge3QTe7ltsnvMfqK+WeDkCFrIuN5uSTocJRlFx RiIs2CuBpL0LS61xoqmhzpC6PWR3CBrk4sJfzyrN+IYc6f3k3xmWA3VgClsr3Gf7IdZS tzMA== 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=TQA66fd+/+23E6icpgeugowUJP9ocgb/+A/k4rgePY0=; b=Zi1X+XJ5cd/dijPM2F7kLXcIhxpsdtAX8mbrR20dJ0HUAlvD3e9KzdZCebUmIdVEBC Cv4lMyK0aYwzPIwGjNaTa7jm38NlLNYkOKRGvefZIXjgcAIypK5KuSv2LRizKorQEQJi oznSqGDnzGTYKA5yvolrxuVjn0CzU+lWSUQ3e3NYTbUeWpp7ooBy0cdP9Rq8LbAkoOAe Rez4qau2K9FVFfY7Qe9w/l+Gx6WEMLT3oKkywIu1DTBfL/TAJHSZMDvXNgtQs5i1lwFA T+HuAKQo2RG3kpWSoi6+dXKw3wnmRwXVBoyDqB75ns5Ep99r6WJfFWJbwl037JMON7X6 sVVA== X-Gm-Message-State: AOAM530nATz83dcXWugNBNhFL0jofEtbtjTEmrszK1X3NOubIujhqb0C KlxUcBO1YgJkom3aKmxmh7p2eOdLkHfK0dK/wTY= X-Google-Smtp-Source: ABdhPJxw2HGcp/x3SYaYqYkT2BSfOP9s1A0sH/d5e/rdP8S8lWx5LOZunLaxHYAXcTkzQW/0o7+kNA+8gDLBZL2QsRQ= X-Received: by 2002:a92:d489:: with SMTP id p9mr2684037ilg.123.1606193761749; Mon, 23 Nov 2020 20:56:01 -0800 (PST) MIME-Version: 1.0 References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> In-Reply-To: From: Fabien Imbault Date: Tue, 24 Nov 2020 05:55:48 +0100 Message-ID: To: Francis Pouatcha Cc: GNAP Mailing List , Dick Hardt , Tom Jones , Denis , Justin Richer Content-Type: multipart/alternative; boundary="0000000000009c0db005b4d320fc" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 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: Tue, 24 Nov 2020 04:56:08 -0000 --0000000000009c0db005b4d320fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francis, I've thought a bit more to what you said. I think I'll give it a try as a separate experiment (in code, not in theory). Not that I would expect it to be included in GNAP, but I kind of like the idea :-) The direct impact for GNAP would be to think about multiple ASs. Will let you know. Fabien Le mer. 18 nov. 2020 =C3=A0 13:06, Francis Pouatcha a =C3= =A9crit : > It would be nice if the protocol was designed at many layers of > abstraction. > > > - The first layer shall design abstract protocol flows, without > specification of the mode and mechanism of interaction. > - The second layer can instantiate the first layer for dedicated > interaction. Here we can talk http, we can define interactions that pr= esume > server based token generation, we can define interaction that run on u= ser > device based token generation. > > This is also the fundament of the structure I proposed for the spec ( > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30). > > /Francis > > ------------------------------ > *From:* Fabien Imbault > *Sent:* Wednesday, November 18, 2020 6:35 AM > *To:* Francis Pouatcha > *Cc:* txauth@ietf.org ; Dick Hardt ; > Tom Jones ; Denis ; > Justin Richer > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Would make sense, but not so easy as we rely heavily on HTTP. Hence the > discussion about deep links and so on. > > An alternative might be provided by wasm/wasi (running a local sandbox on > your phone, for your own AS), but it's really early stage. This also pose= s > another question that Denis has put forward, i.e. how do we handle the > multiple AS scenario (likely to occur then). > > Fabien > > On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha wrote: > > We are drifting away from the original problem space. > > - My original mention was about the "POST" request, that subsumes that > the "AS" is a "Server". Designing a new protocol, we cannot afford thi= s > limitation. > - I just mentioned SIOP to show a known and closed example? Let us not > focus on the device local discovery scheme (like openid:) for now. > - As capability of holding private keys on user device evolves, > server-based issuing of token will be fading out giving way to device = local > generation of token. > > While designing GNAP, let us assume the AS-Role can be exercised on a use= r > device and design the protocol to honor that. > > Best regards, > /Francis > ------------------------------ > *From:* TXAuth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Sent:* Tuesday, November 17, 2020 1:28 PM > *To:* Tom Jones > *Cc:* Fabien Imbault ; Denis ; > GNAP Mailing List ; Justin Richer > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Got it. > > So web apps invoke a openid: deep link and hope there is an app to handle > the openid: scheme? ... and that it is the user's wallet rather than some > malware that has registered openid: on the mobile device? > > A native app can attempt to open a deep link associated with an app, and > will fail if the app is not there. If the app is there, it will be opened= , > so this can't be used to silently test if an app is present, but it does > allow a native app to provide an alternative experience if an app is not > present. I don't think this works with custom schemes ... and I don't kno= w > how it could work from a web app on the phone with the current Safari API= s. > > Apple warns against using custom schemes [1] ... but perhaps they can be > convinced to make openid: a managed scheme similar to mailto:, tel:, > sms:, facetime: ? > > [1] > https://developer.apple.com/documentation/xcode/allowing_apps_and_website= s_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app > > > =E1=90=A7 > > On Tue, Nov 17, 2020 at 10:06 AM Tom Jones > wrote: > > You are - that is not standard which is opeind:// > This is the one step that still needs to be optimized for SIOP to have > good UX. > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt wrote: > > Hi Tom > > I watched your video (I watched at 2X speed) > > Looks like the employment website app that is using localhost:8765 to > communicate with the wallet. Am I correct? > > /Dick > =E1=90=A7 > > On Tue, Nov 17, 2020 at 9:46 AM Tom Jones > wrote: > > Well, here's a demo. Note that in this case the AS is not online all of > the time, so it is really implicit flow and the OIDC id-token comes from > the siop device directly. > (whether this is front-channel or back channel is no longer an interestin= g > question.) > Now if an always-on AS is required, that is possible, but probably beyond > the scope of this effort and would require something like an > agent-in-the-sky (with diamonds). > here is the link to the 9 min video https://youtu.be/Tq4hw7X5SW0 > > Peace ..tom > > > On Tue, Nov 17, 2020 at 9:20 AM Justin Richer wrote: > > Ultimately, in most situations like these in the real world, the hurdle > isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP > (client) needs to have some incentive to trust the assertions and identit= y > information that=E2=80=99s coming from the AS. The same is true for an RS= trusting > tokens from the AS. The hard question is less =E2=80=9Chow=E2=80=9D to do= that (which SSI > answers), but more =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2= =80=99t answer very well, > because it=E2=80=99s a hard question). > > Still: it=E2=80=99s definitely a question about how to support this =E2= =80=9CAS on device=E2=80=9D > element. We=E2=80=99ve got the start of it more than OAuth2/OIDC have by = allowing > the bootstrap of the process from a starting call: the interaction and > continuation URIs handed back by the AS don=E2=80=99t need to be the same= URIs that > the client starts with, so just like SIOP the process can start in HTTP a= nd > potentially move to other communication channels. A major difference is > that we aren=E2=80=99t dependent on the assumption that the user will alw= ays be in > a browser at some stage, and so the whole raft of front-channel messages > that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got an = opportunity to > more explicitly open up alternative communication channels here, and that= =E2=80=99s > something I=E2=80=99d like to see engineered, even if it=E2=80=99s an ext= ension. I=E2=80=99d love > to see a concrete proposal as to how that would work over specific > protocols, starting with what we=E2=80=99ve got today. > > =E2=80=94 Justin > > On Nov 17, 2020, at 12:03 PM, Fabien Imbault > wrote: > > Hi Denis, hi Francis, > > At some point integration with SSI (on the authentication side) will > probably occur, including amongst other possibilities SIOP (since they wo= rk > with OpenID a part of the work will probably be made easier). > > That being said, Denis is right. It's not an AS. Technically it's entirel= y > possible to rely on a decentralized wallet (for instance on your phone) a= nd > a centralized AS. I know of a few studies on how to decentralize the AS > itself (for instance > https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02). > Maybe it exists, but I'm still looking for real scenarios (or even > architectures) where an AS is deployed directly on a phone, and under the > sole authority of the RO, while being compatible with the rest of the > world. > > Cheers, > Fabien > > On Tue, Nov 17, 2020 at 5:45 PM Denis wrote: > > Hello Francis, > > See two comments in line. > > > B) Current Document > > Roles description shall not hold any assumption on the physical structure > of the party fulfilling the roles. > [FI] not sure what you mean > > [FP] for example, we assume the AS is a server! In most SSI based use > cases, the AS will be running on the user device. See SIOP ( > https://identity.foundation/did-siop/). > > I browsed through the two drafts, i.e. : > > - Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, > and representations W3C Working Draft 08 November 2020 > - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working > Group Draft > > At no place within these two documents, it is possible to imagine that > "the AS will be running on the user device". > > From section 3 of the DIF Working Group Draft: > > "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the > SIOP will not return an access token to the RP". > > An Identity Wallet is not an AS. > > > Roles: > -> grant endpoint of the AS: Why is this a post request? This eliminates > the chance of having user device hosted AS (no server). > [FI] what would you propose instead? > Would also be interested to understand better the deployment model when > there is no server. That's something that was discussed several times but > I'm still missing the underlying architecture and use case. > > [FP] See above (SIOP). There will be a lot of identity wallets operated > on end user device. > > See the above comment. Please, do not confuse an Identity Wallet with an > Authentication Server (AS). > > Denis > > > -> Resource Owner (RO) : Authorizes the request? Does it authorize the > request or the access to a resource? > [FI] yes, we should make the wording clearer > > Missing Section Interactions: > --> This section shall introduce the notion of interaction before we star= t > listing interaction types. > [FI] yes > > Interaction Types: > --> I prefer a classification with Redirect, Decoupled and Embedded is. I= n > the draft, we have one redirect and 2 decouple interactions and nothing > else. > [FI] this should be handled as a specific discussion item. As a reminder, > how would you define embedded? > > In practice there's at least these modes: > - redirect and redirect back > - redirect to different browser or device > - user code > - CIBA > > [FP] This classification is limited. > > - Redirect: same device, same or different user agents (browser, > mobile app, desktop app, ...) > - Decoupled: different devices > - Embedded : RC carries RO authorization to AS > > > > Resource Access Request vs. Resource Request > --> Both are mixed up. No clarification of the context of each section. > [FI] could you clarify what you'd expect. Btw on this topic, there's a > more general discussion on whether we should make a distinction or not. > > =E2=80=8B[FP]: Here: > > - Resource Access Request: Requesting Access to a resource. Response > is an access token (or any type of grant) > - Resource Request: Request the resource. Response is the resource (or > a corresponding execution) > > > Token Content Negotiation > --> Not expressed as such. This is central to GNAP and not represented > enough in the document. > [FI] right. This should be a specific discussion item. > > Requesting "User" Information > we identify two types of users: RQ and RO. It will be better not to refer > to a user in this draft, but either to a RQ or an RO. > [FI] yes that would avoid potential misunderstandings. Although in the > end, people will translate RQ into user or end-user most of the time. Cf = in > definition, currently we have Requesting Party (RQ, aka "user") > > > Interaction Again > -> For each interaction type, we will have to describe the protocol flow > and the nature and behavior of involved Roles (Parties), Elements, Reques= ts. > [FI] yes > > > [FP] Will these and into tickets? > > Best regards. > /Francis > > > > -- > 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 > > --0000000000009c0db005b4d320fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis,

I've thought a bit more to what you said. I think I'll give it= a try as a separate experiment (in code, not in theory). Not that I would = expect it to be included in GNAP, but I kind of like the idea :-)

The direct impact for GNAP would = be to think about multiple ASs.=C2=A0

Will let you know.=C2=A0

Fabien=C2=A0

Le mer. 18 nov. 2020 =C3=A0 13:06, Francis P= ouatcha <fpo@adorsys.de> a =C3= =A9crit=C2=A0:
It would be nice if the protocol was designed at many layers of abstraction= .

  • The first layer shall design abstract protocol flows, without specifica= tion of the mode and mechanism of interaction.
  • The second layer can= instantiate the first layer for dedicated interaction. Here we can talk ht= tp, we can define interactions that presume server based token generation, = we can define interaction that run on user device based token generation.
This is also the fundament of the structure I proposed for the spec (<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30" id= =3D"m_8348797445460806175LPlnk338391" target=3D"_blank" rel=3D"noreferrer">= https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).

/Francis

From: = Fabien Imbault <fabien.imbault@gmail.com>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: txauth@ietf.org <txauth@ietf.org>; Dick Hardt <di= ck.hardt@gmail.com>; Tom Jones <thomasclinganjones@gmai= l.com>; Denis <denis.ietf@free.fr>; Justin Richer <jricher= @mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Would make sense, but not so easy as we rely heavily on HT= TP. Hence the discussion about deep links and so on.

An alternative might be provided by wasm/wasi (running a local sandbox= on your phone, for your own AS), but it's really early stage. This als= o poses another question that Denis has put forward, i.e. how do we handle = the multiple AS scenario (likely to occur then).=C2=A0

Fabien=C2=A0

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@ador= sys.de> wrote:
We are drifting away from the original problem space.
  • My original mention was about the "POST" request, that subsum= es that the "AS" is a "Server". Designing a new protoco= l, we cannot afford this limitation.
  • I just mentioned SIOP to show = a known and closed example? Let us not focus on the device local discovery = scheme (like openid:) for now.
  • As capability of holding private key= s on user device evolves, server-based issuing of token will be fading out = giving way to device local generation of token.
While designing GNAP, let us assume the AS-Role can be exercised on a = user device and design the protocol to honor that.

Best regards,
/Francis
From: TXAuth <txauth-bounces@ietf.org&g= t; on behalf of Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Denis= <denis.ietf@free.fr>; GNAP Mailing List <txauth@ietf.org>= ; Justin Richer <jricher@mit.edu>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
=C2=A0
Got it.=C2=A0

So web apps invoke a openid: deep link and hope there is an app to han= dle the openid: scheme? ... and that it is the user's wallet rather tha= n some malware that has registered openid: on the mobile device?

A native app can attempt to open a deep link associated with an app, a= nd will fail if the app is not there. If the app is there, it will be opene= d, so this can't be used to silently test if an app is present, but it = does allow a native app to provide an alternative experience if an app is not present. I don't think this wo= rks with custom schemes ... and I don't know how it could work from a w= eb app on the phone with the current Safari APIs.

Apple warns against using custom schemes [1] ... but perhaps they can = be convinced to make openid: a managed scheme similar to mailto:, tel:, sms= :, facetime: ?



3D""=E1=90=A7

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <t= homasclinganjones@gmail.com> wrote:
You are - that is not standard which is opeind://
This is the one step that still needs to be optimized for SIOP to have= good UX.
Peace ..tom


On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hard= t@gmail.com> wrote:
Hi Tom

I watched your video (I watched at 2X speed)

Looks like the employment website app that is using localhost:8765 to = communicate with the wallet. Am I correct?

/Dick=C2=A0
3D""=E1=90=A7

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <th= omasclinganjones@gmail.com> wrote:
Well, here's a demo. Note that in this case the AS is = not online all of the time, so it is really implicit flow and the OIDC id-t= oken comes from the siop device directly.
(whether this is front-channel or back channel is no longer an interes= ting question.)
Now if an always-on AS is required, that is possible, but probably bey= ond the scope of this effort and would require something like an agent-in-t= he-sky=C2=A0(with diamonds).
here is the link to the 9 min video=C2= =A0=C2=A0=C2=A0https://youtu.= be/Tq4hw7X5SW0
Peace ..tom


On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mi= t.edu> wrote:
Ultimately, in most situations like these in the real world, the hurdl= e isn=E2=80=99t technical compatibility so much as it is trust compatibilit= y. The RP (client) needs to have some incentive to trust the assertions and= identity information that=E2=80=99s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard q= uestion is less =E2=80=9Chow=E2=80=9D to do that (which SSI answers), but m= ore =E2=80=9Cwhy=E2=80=9D to do that (which SSI doesn=E2=80=99t answer very= well, because it=E2=80=99s a hard question).

Still: it=E2=80=99s definitely a question about how to support this = =E2=80=9CAS on device=E2=80=9D element. We=E2=80=99ve got the start of it m= ore than OAuth2/OIDC have by allowing the bootstrap of the process from a s= tarting call: the interaction and continuation URIs handed back by the AS don=E2=80=99t need to be the same URIs that the client starts with,= so just like SIOP the process can start in HTTP and potentially move to ot= her communication channels. A major difference is that we aren=E2=80=99t de= pendent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel mess= ages that SIOP relies on doesn=E2=80=99t fly. That said, we=E2=80=99ve got = an opportunity to more explicitly open up alternative communication channel= s here, and that=E2=80=99s something I=E2=80=99d like to see engineered, even if it=E2=80=99s an extension. I=E2=80=99d love to see a concrete prop= osal as to how that would work over specific protocols, starting with what = we=E2=80=99ve got today.=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@= gmail.com> wrote:

Hi Denis, hi Francis,=C2=A0

At some point integration with SSI (on the authentication side) will p= robably occur, including amongst other possibilities SIOP (since they work = with OpenID a part of the work will probably be made easier).=C2=A0

That being said, Denis is right. It's not an AS. Technically it= 9;s entirely possible to rely on a decentralized wallet (for instance on yo= ur phone) and a centralized AS. I know of a few studies on how to decentral= ize the AS itself (for instance=C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even= architectures) where an AS is deployed directly on a phone, and under the = sole authority of the RO, while being compatible with the rest of the world= .=C2=A0

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <denis.ietf@free.= fr> wrote:
Hello=C2=A0 Francis,

See two comments in line.


B) Current Document

Roles description shall not hold any assump= tion on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
= =C2=A0[FP] for example, we assume the AS is a server! In most SSI based use= cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop= /).

I browsed through the two drafts, i.e. :

  • Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, an= d representations W3C Working Draft 08 November 2020
  • Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working = Group Draft

At no place within these two documents, it is possible to imagine that &= quot;the AS will be running on the user device".

From section 3 of the DIF Working Group Draft:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Unlike the OIDC Authorization Code = Flow as per [OIDC.Core], the SIOP will not return an access token to the RP= ".

An Identity Wallet is not an AS.

=
=
Roles:=C2=A0
-> grant endpoint of the AS: Why is this a pos= t request? This eliminates the chance of having user device hosted AS (no s= erver).
[FI] what would you propose i= nstead?
Would also be interested to u= nderstand better the deployment model when there is no server. That's s= omething that was discussed several times but I'm still missing the und= erlying architecture and use case.
= =C2=A0[FP] See above (SIOP). There will be a lot of identity wallets operat= ed on end user device.

See the above comment. Please, do not confuse an Identity Wallet with an= Authentication Server (AS).

Denis

=
-> Resource Owner (RO) : Authorizes the reques= t? Does it authorize the request or the access to a resource?
[FI] yes, we should make the = wording clearer

Missing Section Interactions:
--> This section shall introduce the notion of= interaction before we start listing interaction types.
[FI] yes=C2=A0

Interaction Types:
--> I prefer a classification with Redirect, D= ecoupled and Embedded is. In the draft, we have one redirect and 2 decouple= interactions and nothing else.
[FI] this should be handled a= s a specific discussion item. As a reminder, how would you define embedded?=

In practice there's at le= ast these modes:
- redirect and redirect back<= /font>
- redirect to different brows= er or device
- user code
- CIBA
[FP] This classification is limited.
  • Redirect: same device, same or different user agents (browser, mobile a= pp, desktop app, ...)
  • Decoupled: different devices
  • Embedded= : RC carries RO authorization to AS
=

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the= context of each section.
[FI] could you clarify what y= ou'd expect.=C2=A0 Btw on this topic, there's a more general discus= sion on whether we should make a distinction or not.=C2=A0
= =E2=80=8B= [FP]: Here:
  • Resource Access Request: Requesting Access= to a resource. Response is an access token (or any type of grant)
  • Resource Request: Request the resource. Response is the resour= ce (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to = GNAP and not represented enough=C2=A0 in the document.
[FI] right. This should be a = specific discussion item.=C2=A0

Requesting "User" Information
we identify two types of users: RQ and RO. It wil= l be better not to refer to a user in this draft, but either to a RQ or an = RO.
[FI] yes that would avoid pot= ential misunderstandings. Although in the end, people will translate RQ int= o user=C2=A0or end-user most of the time. Cf in definition, currently we ha= ve=C2=A0Requesting Party (RQ, aka "user")


Interaction Again
-> For each interaction type, we will have to = describe the protocol flow and the nature and behavior of involved Roles (P= arties), Elements, Requests.
[FI] yes=C2=A0=C2=A0

= [FP] Will these and into tickets?
=
= Best regards.
= /Francis



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

--
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>
--0000000000009c0db005b4d320fc-- From nobody Wed Nov 25 08:27: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 221533A19B6 for ; Wed, 25 Nov 2020 08:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 DojHxUkWZHza for ; Wed, 25 Nov 2020 08:26:52 -0800 (PST) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 35EEB3A198F for ; Wed, 25 Nov 2020 08:26:52 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id t9so3166989edq.8 for ; Wed, 25 Nov 2020 08:26:52 -0800 (PST) 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; bh=fEPwZu45V3Y//kaJgQQAZoh9WNGbbSXJ7RknYDUt68c=; b=PZbmZLKJsy5QXTR/MHY4mAWMBjrsM9PdW773HWgWv9xwfhhXrxUs9W5OGn5qr4kNCy WPUe74+fE7dbmNT/WD0N4lweOvQLus7q6wNEqAHIYpI9g+MP3mOiOf1dKxmeyxjp+Ws8 2u4uirsKIrGxbNf+Q/cPoB4alyBWrfe5nG9qXhDqqyXMeTHHDIgKj01R1NayLaFoo4Q7 ISc1tH7yOshM4NmzxAPwF1nOrn/VgIisfAIH+gp1SiBoiHhQ8HvnY/y3G02uRQt8mCIB j7eny1k9npF4tQbXtcCuTy0jIIEG2/7VuYTCd1KMHqTTFQsf344WCWmUbnMcJgcZwGki 4r1g== 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; bh=fEPwZu45V3Y//kaJgQQAZoh9WNGbbSXJ7RknYDUt68c=; b=WkzBUIAbd21Jb59pos9KRwANhZ3I4UHvxkXASv7ZkWEaL6GVKeovKoaFVSXc5YM01Y KjFN407vkzBko9reRuOX4b3pndzGr8WX1BdtFtpiM4oHlURM1dgOE0xN079Ay8TkdFzE 4xxtsI6N+5j9ijoH3Y8vLFEpQXUtBpqOzJyz6FLNNPNzxm64yb5Vg8qXO186XnX7qFei PsEpDFO27T7reTo9HcuwpZrkQnQE2uAabpmib8RtOrBmwExO09PZJkgxDmfnz1N5ddfJ 89vUlw0QQZuAbmIWMFojqxgklrI1tJ8lUC+2wtMpMcTuEHE6O4kiNqCnHuBmCiJhT5yQ LzWQ== X-Gm-Message-State: AOAM533LRir9dG5xhSNP26m3e1a7j3GJBNa6XJqzABXTC9WB2PkU8DYY kgBgbmDYuAUjKhEiqEa4JsNrkiSbCslt3w== X-Google-Smtp-Source: ABdhPJzjxOYS570CLjEg9Hdk3Zc/S6fLv9FHq3udZdCt4GEx8Xs3bqn17XcpYIu5vtBier/WH5LLWQ== X-Received: by 2002:a05:6402:2065:: with SMTP id bd5mr4229118edb.48.1606321610344; Wed, 25 Nov 2020 08:26:50 -0800 (PST) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id b15sm1588513edv.85.2020.11.25.08.26.49 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Nov 2020 08:26:49 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.43.20110804 Date: Wed, 25 Nov 2020 18:26:48 +0200 From: Yaron Sheffer To: GNAP Mailing List Message-ID: <4858764D-7743-4D4D-90E8-F9B593B3E78D@gmail.com> Thread-Topic: GNAP minutes from IETF-109 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3689173609_154647603" Archived-At: Subject: [GNAP] GNAP minutes from IETF-109 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, 25 Nov 2020 16:27:01 -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_3689173609_154647603 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable We have uploaded the draft minutes here: https://datatracker.ietf.org/meeti= ng/109/materials/minutes-109-gnap-00.md =20 Thank you Dave and Bron for taking notes! =20 Please let us know if anything is missing or you discover any mistakes. =20 If you prefer, all sessions from IETF-109 are also available on Youtube. Ou= rs is here: https://www.youtube.com/watch?v=3D8_gX6itLsxM =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 --B_3689173609_154647603 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

We have uploaded the draft minutes here: https://d= atatracker.ietf.org/meeting/109/materials/minutes-109-gnap-00.md

 <= /o:p>

Thank you = Dave and Bron for taking notes!

 

Please let us know if anything is missing or yo= u discover any mistakes.

 

If you prefer, all sessions from IETF-109 are also ava= ilable on Youtube. Ours is here: https://www.youtube.com/watch?v=3D8_gX6itLsxM=

 

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

--B_3689173609_154647603-- From nobody Wed Nov 25 08:36: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 0C0F93A1A27 for ; Wed, 25 Nov 2020 08:36:55 -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_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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jomSC1wcgxAA for ; Wed, 25 Nov 2020 08:36:52 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 583D83A1A20 for ; Wed, 25 Nov 2020 08:36:52 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id r9so2740876ioo.7 for ; Wed, 25 Nov 2020 08:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=l1kmn6gkNMdAPdihwPtwHAicqtuYY6hx7XdDq2kly/4=; b=jVacd2DOMgyUSkOFzoGmF7wqQQgabbUGb8hrImOJLPR6LkiLoKfwQvg+9qO3ET9Rjp mGylR3so4TdMjiStpdJip+nAWST0wVxsZTXO86Bl38dXwCR7kc56MDhzCufOmoYcxItX 8bcp9dmGAJRkGsCiUzL6Me/aNuOz88rjkHnVnD9dNGStKcC5UxEqmmas1rJiOKNcoH1u /1fLBnGM4+5b/0Qqc5hgHChHhoRTaMsysOypLYEwjnJXcSG8XF3ehwLy0qCqDXHpay1w OsBnNsW7Gw0J+LkMkXqqL9Vy1hb6p2NbnGzDsurFY+5jV4jRlWfB97j2K02NfQMIIHYX Filw== 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=l1kmn6gkNMdAPdihwPtwHAicqtuYY6hx7XdDq2kly/4=; b=ijLsfsL5zJsxJgeTp5Ow1gra1iy1wbXvvh8TyRH6xqXfdaOjM/p+uYm2YTD+3l0zeZ 9zxLZMNe7Lo401mojWi0DZEapaoBIEGD52rb5LWS315nkV8/IspOrpSp48y/IooleE9O L3aj9A+U4OQKnVEjFXlZ+WQlmibQS+/KuHDHXI3xMaInPoYYi6mHdQ9r4mdd/1ERYdfC YzCMHJzoMDg9kI2RRTvJ4arNGW56SQFCCGn6WhdWfgaApJ+9lM8qxNJTIM1I9fZ4JlfB wmJiXhkBGwUHcE2L15Xp7f4pk6seoluuSVDAUFsofP/nJ4ABW3Kio21XftnORqmWUvjZ kmVg== X-Gm-Message-State: AOAM533pXmaZI+eM1QKDWFIMnB5IDnmAaxPG2oYGtTRbPU2UO6AL0dCX Fiq/oMmN/N0et+7fAyZE03uqdSbBr2wRCQ== X-Google-Smtp-Source: ABdhPJzDn9WqdJA+XIb2AJOpmKHMUVKQO/9sahXt6H20Lgqk35dxcOPV6cXS9PukD9Fk+oXsv4e1UQ== X-Received: by 2002:a6b:3756:: with SMTP id e83mr3256561ioa.127.1606322210515; Wed, 25 Nov 2020 08:36:50 -0800 (PST) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com. [209.85.166.175]) by smtp.gmail.com with ESMTPSA id p28sm1830713ilb.9.2020.11.25.08.36.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 08:36:49 -0800 (PST) Received: by mail-il1-f175.google.com with SMTP id t13so2714971ilp.2 for ; Wed, 25 Nov 2020 08:36:49 -0800 (PST) X-Received: by 2002:a92:ab0f:: with SMTP id v15mr3663403ilh.17.1606322208903; Wed, 25 Nov 2020 08:36:48 -0800 (PST) MIME-Version: 1.0 From: Aaron Parecki Date: Wed, 25 Nov 2020 08:36:37 -0800 X-Gmail-Original-Message-ID: Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000a81a2705b4f1089e" Archived-At: Subject: [GNAP] GNAP Editors' Use of GitHub Issues 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, 25 Nov 2020 16:36:55 -0000 --000000000000a81a2705b4f1089e Content-Type: text/plain; charset="UTF-8" The editors met yesterday to discuss the issues that were pulled out of the previous draft text and document a process for how to resolve these and future issues. We would like to explain how we plan on using labels on GitHub issues to keep track of discussions and keep things moving. When there are substantive issues or pull requests, the editors will avoid merging or closing those outright, and instead mark them as "pending", so that these can be brought to the attention of the larger group. If no additional discussion happens on these, the merge or close action will be taken in 7 days. Note for this first round we are setting the deadline for the issues below as Dec 11th due to the US holiday and the fact that this is the first time using this process. "Pending Merge" When specific text is proposed in a PR (by anyone, not limited to the editors), and the editors believe this text reflects the consensus of the working group, this marks that the PR will be merged in 7 days unless there is a clear alternative proposal accepted by the working group. "Pending Close" When the editors believe an issue no longer needs discussion, we'll mark it "Pending Close". The issue will be closed in 7 days unless someone brings new information to the discussion. This tag is not applied to issues that will be closed by a specific pull request. There are two additional labels we will use to flag issues to the group. "Needs Text" The editors suggest this issue needs additional text in the spec to clarify why this section is needed and under what circumstances. Without a concrete proposal of text to be included in the spec, this section will be removed in a future update. "Postponed" This issue can be reconsidered in the future with a more concrete discussion but is not targeted for immediate concrete changes to the spec text. When used on its own, this label does not indicate that an issue is targeted to be closed. An issue may also be marked "Pending Close", and this is used so that we can distinguish closed issues between discussions that have concluded or things that we may want to revisit in the future. Remember that closed issues are not deleted and their contents are still findable and readable, and that new issues can reference closed issues. With these labels in mind, here are the list of issues and their statuses we were able to discuss on our last editor's call. The action on these pending issues will be taken on Dec 11th to give the group enough time to review this list. For this first round, many of the issues are marked "Pending Close" as we're looking for low hanging fruit to prune the list of issues down. In the future, you can expect to see more "Pending Merge" issues as we're bringing proposed text to review by the WG. Postponed: * Generic claim extension mechanism ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 Pending Merge: * Make access token mandatory for continuation API calls ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 Postponed and Pending Close: * Fetchable Keys ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 * Including OpenID Connect Claims ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 * Application communication with back-end ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 * Additional post-interaction protocols ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 Pending Close: * HTTP PUT vs POST for rotating access tokens ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 * Use of hash with unique callback URL ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 * Interaction considerations ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 * Expanding dynamic reference handles ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 * Post interaction callback nonce ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73 * Unique callback URIs ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 * Instance identifier ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 * Requesting resources by reference ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36 * Mapping resource references ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 --- Aaron Parecki https://aaronparecki.com --000000000000a81a2705b4f1089e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The editors met yesterday to discuss the issues that were = pulled out of the previous draft text and document a process for how to res= olve these and future issues. We would like to explain how we plan on using= labels on GitHub issues to keep track of discussions and keep things movin= g.

When there are substantive issues or pull requests, the editors w= ill avoid merging or closing those outright, and instead mark them as "= ;pending", so that these can be brought to the attention of the larger= group. If no additional discussion happens on these, the merge or close ac= tion will be taken in 7 days. Note for this first round we are setting the = deadline for the issues below as Dec 11th due to the US holiday and the fac= t that this is the first time using this process.

"Pending Merg= e"
When specific text is proposed in a PR (by anyone, not limited t= o the editors), and the editors believe this text reflects the consensus of= the working group, this marks that the PR will be merged in 7 days unless = there is a clear alternative proposal accepted by the working group.
"Pending Close"
When the editors believe an issue no longer n= eeds discussion, we'll mark it "Pending Close". The issue wil= l be closed in 7 days unless someone brings new information to the discussi= on. This tag is not applied to issues that will be closed by a specific pul= l request.

There are two additional labels we will use to flag issue= s to the group.

"Needs Text"
The editors suggest this i= ssue needs additional text in the spec to clarify why this section is neede= d and under what circumstances. Without a concrete proposal of text to be i= ncluded in the spec, this section will be removed in a future update.
"Postponed"
This issue can be reconsidered in the future wit= h a more concrete discussion but is not targeted for immediate concrete cha= nges to the spec text. When used on its own, this label does not indicate t= hat an issue is targeted to be closed. An issue may also be marked "Pe= nding Close", and this is used so that we can distinguish closed issue= s between discussions that have concluded or things that we may want to rev= isit in the future. Remember that closed issues are not deleted and their c= ontents are still findable and readable, and that new issues can reference = closed issues.

With these labels in mind, here are the list of issue= s and their statuses we were able to discuss on our last editor's call.= The action on these pending issues will be taken on Dec 11th to give the g= roup enough time to review this list. For this first round, many of the iss= ues are marked "Pending Close" as we're looking for low hangi= ng fruit to prune the list of issues down. In the future, you can expect to= see more "Pending Merge" issues as we're bringing proposed t= ext to review by the WG.

Postponed:

* Generic claim extension= mechanism
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/1= 31

Pending Merge:

* Make access token mandatory for conti= nuation API calls
** https://github.com/ietf-wg-gnap/gnap-core-protocol/pul= l/129

Postponed and Pending Close:

* Fetchable Keys
**= h= ttps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47
* Includ= ing OpenID Connect Claims
** https://github.com/ietf-wg-gnap/gnap-core-pro= tocol/issues/64
* Application communication with back-end
** https:= //github.com/ietf-wg-gnap/gnap-core-protocol/issues/82
* Additional = post-interaction protocols
** https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/issues/83

Pending Close:
=C2=A0 =C2=A0
* HTTP PUT = vs POST for rotating access tokens
** https://github.com/ietf-wg-gnap/gna= p-core-protocol/issues/100
* Use of hash with unique callback URL** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84
* Int= eraction considerations
** https://github.com/ietf-wg-gnap/gnap-core-proto= col/issues/81
* Expanding dynamic reference handles
** https://gith= ub.com/ietf-wg-gnap/gnap-core-protocol/issues/76
* Post interaction = callback nonce
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/73
* Unique callback URIs
** https://github.com/ietf-wg-gnap/gna= p-core-protocol/issues/55
* Instance identifier
** https://github.c= om/ietf-wg-gnap/gnap-core-protocol/issues/46
* Requesting resources = by reference
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/= 36
* Mapping resource references
** https://github.com/ietf-wg-gnap= /gnap-core-protocol/issues/35

---<= /div>Aaron Parecki

--000000000000a81a2705b4f1089e-- From nobody Wed Nov 25 10:27: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 CD9533A1537 for ; Wed, 25 Nov 2020 10:27:48 -0800 (PST) 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 d0sC--ZMU-mS for ; Wed, 25 Nov 2020 10:27:44 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 5960A3A14FF for ; Wed, 25 Nov 2020 10:27:44 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id q16so3557339edv.10 for ; Wed, 25 Nov 2020 10:27:44 -0800 (PST) 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=IspZN1q2osmnlY5q72FJRN04XA6r1ALdL46bNTBTDnc=; b=ZIWjDmVFbIPb3TG4fX6g3cs0yMskb1igh4FuAQDVqPtOc1ejz7RF5vKwctrrZf8HJc DxDLeWy6INPqM2G4VCvEpMyOjMqjM4USe9k4T79B8r6TNYBVMOFHT8uwSyHpnO8gejE6 12C8QffUlSTIGZyiDHZmA26YUEjKRe78bvkR925BWdHzqWTviIJaKfvlCzNe3OhbB9mX m3S57tUrjO+FewPyA3d4WpaNFWnkXdGRq9w+p4xXiy4btWaUzblsjs4zYyAHHteH2BJu Y9Jvw7CdMUT0tsm3EHC1ZfZM+pbh1jy6PGzPqj4VvADUEQ97njJUtKEsipSoi7uSCJw/ y/qA== 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=IspZN1q2osmnlY5q72FJRN04XA6r1ALdL46bNTBTDnc=; b=qt2ywInVFkGuRl70sSId93/vcK1chJXCoPizonRgkQil08ZM2sN26CRvqODltFMGxl CdwhiOGWnqEV1etEwKic9ULutZ11hYAjoGnzMVk+rWXjE5XfY2m/4VOF7J/nolTmnWX4 rV/+XF8rWG+kqFAIqxD4oWKPpRB7uETydscT3NUoMZGSrwq6/67TXz2FeKNHmbw9sRyK EVuNAYdTKHmaFRT4pDfFNplxwZDg7mUDOFl/7riY3Zq5/M3W/G1jsQnSztmOMzLrBUyG PlZwqJYUtYnHQsYzJJpTrA8YuIm9ulJWVEQsRRx4SvJK8OiRPw/nlNT5P7rT0B6oV0Ui 8McQ== X-Gm-Message-State: AOAM532Tpw/SBd+fLgfqptHMWF0E+/5RqQTM2wM22XiaKGxb4L+ZEeg0 jgiffqOIqllQUP0p2C0gZvgmzcjs6b4lWg== X-Google-Smtp-Source: ABdhPJzdup5CZ9gFeQBll/J3qePSmNbCkvgwwfqUdWrQIPqJUdPF57DqUnGxVmw2CqTiGK4fgoFtPg== X-Received: by 2002:a50:9b5c:: with SMTP id a28mr4767452edj.139.1606328862579; Wed, 25 Nov 2020 10:27:42 -0800 (PST) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id rs27sm1753271ejb.34.2020.11.25.10.27.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Nov 2020 10:27:42 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.43.20110804 Date: Wed, 25 Nov 2020 20:27:40 +0200 From: Yaron Sheffer To: Aaron Parecki , GNAP Mailing List Message-ID: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> Thread-Topic: [GNAP] GNAP Editors' Use of GitHub Issues References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3689180861_211338390" Archived-At: Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues 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, 25 Nov 2020 18:27:49 -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_3689180861_211338390 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Commenting on the proposed process (chair hat off): =20 I think =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once something is clos= ed, we should be reasonably confident that it is resolved for good. People r= arely search through closed issues. =20 Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. Instead, I sugge= st to mark such issues with future milestones, e.g. =E2=80=9CIETF110=E2=80=9D, meaning t= hat at this time we will review the issue. Otherwise, the =E2=80=9Cpostponed=E2=80=9D is= sues will probably suffer the destiny of all =E2=80=9Clow priority=E2=80=9D issues =E2=80=93 t= hey will be ignored for months and eventually closed en masse. See [1] for G= itHub milestones. =20 Otherwise I am fine with the rest of the process. =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 [1] https://docs.github.com/en/free-pro-team@latest/github/managing-your-wo= rk-on-github/about-milestones =20 =20 From: TXAuth on behalf of Aaron Parecki Date: Wednesday, November 25, 2020 at 18:37 To: GNAP Mailing List Subject: [GNAP] GNAP Editors' Use of GitHub Issues =20 The editors met yesterday to discuss the issues that were pulled out of the= previous draft text and document a process for how to resolve these and fut= ure issues. We would like to explain how we plan on using labels on GitHub i= ssues to keep track of discussions and keep things moving. When there are substantive issues or pull requests, the editors will avoid = merging or closing those outright, and instead mark them as "pending", so th= at these can be brought to the attention of the larger group. If no addition= al discussion happens on these, the merge or close action will be taken in 7= days. Note for this first round we are setting the deadline for the issues = below as Dec 11th due to the US holiday and the fact that this is the first = time using this process. "Pending Merge" When specific text is proposed in a PR (by anyone, not limited to the edito= rs), and the editors believe this text reflects the consensus of the working= group, this marks that the PR will be merged in 7 days unless there is a cl= ear alternative proposal accepted by the working group. "Pending Close" When the editors believe an issue no longer needs discussion, we'll mark it= "Pending Close". The issue will be closed in 7 days unless someone brings n= ew information to the discussion. This tag is not applied to issues that wil= l be closed by a specific pull request. There are two additional labels we will use to flag issues to the group. "Needs Text" The editors suggest this issue needs additional text in the spec to clarify= why this section is needed and under what circumstances. Without a concrete= proposal of text to be included in the spec, this section will be removed i= n a future update. "Postponed" This issue can be reconsidered in the future with a more concrete discussio= n but is not targeted for immediate concrete changes to the spec text. When = used on its own, this label does not indicate that an issue is targeted to b= e closed. An issue may also be marked "Pending Close", and this is used so t= hat we can distinguish closed issues between discussions that have concluded= or things that we may want to revisit in the future. Remember that closed i= ssues are not deleted and their contents are still findable and readable, an= d that new issues can reference closed issues. With these labels in mind, here are the list of issues and their statuses w= e were able to discuss on our last editor's call. The action on these pendin= g issues will be taken on Dec 11th to give the group enough time to review t= his list. For this first round, many of the issues are marked "Pending Close= " as we're looking for low hanging fruit to prune the list of issues down. I= n the future, you can expect to see more "Pending Merge" issues as we're bri= nging proposed text to review by the WG. Postponed: * Generic claim extension mechanism ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 Pending Merge: * Make access token mandatory for continuation API calls ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 Postponed and Pending Close: * Fetchable Keys ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 * Including OpenID Connect Claims ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 * Application communication with back-end ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 * Additional post-interaction protocols ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 Pending Close: =20 * HTTP PUT vs POST for rotating access tokens ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 * Use of hash with unique callback URL ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 * Interaction considerations ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 * Expanding dynamic reference handles ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 * Post interaction callback nonce ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73 * Unique callback URIs=20 ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 * Instance identifier ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 * Requesting resources by reference ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36 * Mapping resource references ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 --- Aaron Parecki https://aaronparecki.com =20 -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3689180861_211338390 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Commenting on the pro= posed process (chair hat off):

 <= /o:p>

I think =E2=80=9Cpostponed=E2=80=9D issues should not be clo= sed. Once something is closed, we should be reasonably confident that it is = resolved for good. People rarely search through closed issues.

 

Moreover, IMO th= e label =E2=80=9Cpostponed=E2=80=9D is not actionable. Instead, I suggest to mark such i= ssues with future milestones, e.g. =E2=80=9CIETF110=E2=80=9D, meaning that at this time = we will review the issue. Otherwise, the =E2=80=9Cpostponed=E2=80=9D issues will probabl= y suffer the destiny of all =E2=80=9Clow priority=E2=80=9D issues =E2=80=93 they will be ignor= ed for months and eventually closed en masse. See [1] for GitHub milestones.=

 

Ot= herwise I am fine with the rest of the process.

 

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

 

[1] https://docs.github.com/en/f= ree-pro-team@latest/github/managing-your-work-on-github/about-milestones

 

&= nbsp;

From: TXAuth= <txauth-bounces@ietf.org> on behalf of Aaron Parecki <aaron@pareck= i.com>
Date: Wednesday, November 25, 2020 at 18:37
To: GNAP Mailing List <txauth@ietf.org>
Subject: [GNAP] GNAP E= ditors' Use of GitHub Issues

 

The editors met yesterday to discuss the issues that were pulled out= of the previous draft text and document a process for how to resolve these = and future issues. We would like to explain how we plan on using labels on G= itHub issues to keep track of discussions and keep things moving.

Whe= n there are substantive issues or pull requests, the editors will avoid merg= ing or closing those outright, and instead mark them as "pending",= so that these can be brought to the attention of the larger group. If no ad= ditional discussion happens on these, the merge or close action will be take= n in 7 days. Note for this first round we are setting the deadline for the i= ssues below as Dec 11th due to the US holiday and the fact that this is the = first time using this process.

"Pending Merge"
When spec= ific text is proposed in a PR (by anyone, not limited to the editors), and t= he editors believe this text reflects the consensus of the working group, th= is marks that the PR will be merged in 7 days unless there is a clear altern= ative proposal accepted by the working group.

"Pending Close&quo= t;
When the editors believe an issue no longer needs discussion, we'll ma= rk it "Pending Close". The issue will be closed in 7 days unless s= omeone brings new information to the discussion. This tag is not applied to = issues that will be closed by a specific pull request.

There are two = additional labels we will use to flag issues to the group.

"Need= s Text"
The editors suggest this issue needs additional text in the = spec to clarify why this section is needed and under what circumstances. Wit= hout a concrete proposal of text to be included in the spec, this section wi= ll be removed in a future update.

"Postponed"
This issue= can be reconsidered in the future with a more concrete discussion but is no= t targeted for immediate concrete changes to the spec text. When used on its= own, this label does not indicate that an issue is targeted to be closed. A= n issue may also be marked "Pending Close", and this is used so th= at we can distinguish closed issues between discussions that have concluded = or things that we may want to revisit in the future. Remember that closed is= sues are not deleted and their contents are still findable and readable, and= that new issues can reference closed issues.

With these labels in mi= nd, here are the list of issues and their statuses we were able to discuss o= n our last editor's call. The action on these pending issues will be taken o= n Dec 11th to give the group enough time to review this list. For this first= round, many of the issues are marked "Pending Close" as we're loo= king for low hanging fruit to prune the list of issues down. In the future, = you can expect to see more "Pending Merge" issues as we're bringin= g proposed text to review by the WG.

Postponed:

* Generic clai= m extension mechanism
** https://github.com/ietf-wg-gnap/gnap-core-protocol/i= ssues/131

Pending Merge:

* Make access token mandatory for= continuation API calls
** https://github.com/ietf-wg-gnap/gnap-core-protocol/p= ull/129

Postponed and Pending Close:

* Fetchable Keys
*= * htt= ps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47
* Including= OpenID Connect Claims
** https://github.com/ietf-wg-gnap/gnap-core-protocol/i= ssues/64
* Application communication with back-end
** https://github.co= m/ietf-wg-gnap/gnap-core-protocol/issues/82
* Additional post-interac= tion protocols
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83=

Pending Close:
   
* HTTP PUT vs POST for rotat= ing access tokens
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/100
* Use of hash with unique callback URL
** https://github.com/ietf= -wg-gnap/gnap-core-protocol/issues/84
* Interaction considerations** h= ttps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81
* Expandi= ng dynamic reference handles
** https://github.com/ietf-wg-gnap/gnap-core-prot= ocol/issues/76
* Post interaction callback nonce
** https://github.com/= ietf-wg-gnap/gnap-core-protocol/issues/73
* Unique callback URIs
= ** ht= tps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55
* Instance= identifier
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46
* Requesting resources by reference
** https://github.com/ietf-wg-gnap/gn= ap-core-protocol/issues/36
* Mapping resource references
** https://git= hub.com/ietf-wg-gnap/gnap-core-protocol/issues/35

---

Aa= ron Parecki

 

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

--B_3689180861_211338390-- From nobody Wed Nov 25 12:27: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 365783A1A8A for ; Wed, 25 Nov 2020 12:27:31 -0800 (PST) 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 r98SIDgIDtCe for ; Wed, 25 Nov 2020 12:27:28 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450: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 BA8123A18C0 for ; Wed, 25 Nov 2020 12:27:27 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id y10so3633970ljc.7 for ; Wed, 25 Nov 2020 12:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ePvG01/otAgvDUG3eLV5vavs7r1WICwoUASwwJOOEw=; b=vLP6Qj49TGHIcd/3Dq/TdyJpvm5Q3JiY8XBANLW6wyrWhOOgQnNYD5mFt362qZ5UI/ 0fFboD1dDerITDKrKphybAwl1N9ZZg4U3Qf3TRdxmnjPC/Dr6wIyBX7GRPcth/enwPgF pjhDrnM3cOZ5ykj4q7KLN5xQMZOg4WHfDuBag7A9vny2fxLVwmieroCrwJwzUyBdsRnI JhHW1hcIiH3WkC1HlO3pchGXlBE9/II1wAn0MI6ufDwIfv9mys09AREI9y2VqEpL4TUQ 8O2/MrajITZd4WSfmVsFNwwMCLl9O0HBDJrbk2Cc2FuPutZjn09OTY685Huz2RCyPr+O Q0LQ== 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=1ePvG01/otAgvDUG3eLV5vavs7r1WICwoUASwwJOOEw=; b=We4iTRYE8+dNFxopOrfdNICpxNUy288LkUNBEsZ0o0IHs81HifwfgjFy8yc5ZpHWAY E25dRNQA/p8kqHLV9osByuh19SdwBao+Tp1AsSvXNkr1kBcN5JrF3y85tKbixj2Orvef tD21BTg55fkiOR9Flw5YYEtq7K3+uctpRBzt1TuWGngaET7BYb4pSKTGNwXGs2/kzQb4 F6AmU0OdxFKECtctUwQsLfr/cXRaBtLgr7/e1U3Z+9l6ks0X8Kwg3mgXwvN4h5e7ak/W oZDH3q25rAloLVJGAUSPYzFfaOVBl13Z8uipiZCMu378girGM8cb6qdiBlFW3kW+DcfX 5oUg== X-Gm-Message-State: AOAM531E34FRDJ1/6x+7beEPNM4i5PFThI4wuqtyrD+3qTyEIR6xSHYe n3J6L2GifwO8Nao8wTHHq3yXQ3eQ6B5Y5UQSMOU= X-Google-Smtp-Source: ABdhPJzIjzyYWnhLT3a5v6vCksuIHrgW8AJj42F2fvrnXYI+lbSnXS7RKwLxqplwMWZMnfVBmUJzKClrM8FNGm3ufgI= X-Received: by 2002:a2e:984e:: with SMTP id e14mr1878608ljj.110.1606336045446; Wed, 25 Nov 2020 12:27:25 -0800 (PST) MIME-Version: 1.0 References: <9D3D60CC-5019-4CC2-BE2D-4EF789FABE31@mit.edu> In-Reply-To: <9D3D60CC-5019-4CC2-BE2D-4EF789FABE31@mit.edu> From: Dick Hardt Date: Wed, 25 Nov 2020 12:26:48 -0800 Message-ID: To: Justin Richer Cc: Fabien Imbault , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000060fa2f05b4f44184" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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, 25 Nov 2020 20:27:31 -0000 --00000000000060fa2f05b4f44184 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are numerous issues with the proposal: 1) It is not an "access token". Just because it is sent in the HTTP Authorization header does not make it an access token. The client has already authenticated before the "access token" is presented. The AS already knows what the client is authorized to do at the AS before the "access token" is issued, so it is not needed to represent authorization as an access token is with an RS. The "access token" is serving the purpose that the transaction handle served in the past -- the context of the transaction. Per my earlier comments, this "access token" is more like a cookie. 2) Calling it an "access token" is changing the well known meaning of an access token as used in OAuth. The client authenticates to the AS APIs in OAuth 2.0, it does not present an access token. Access tokens are presented by a client to an RS to prove authorization. 3) What the client has to do with the "access token" is not the same as access tokens for an RS. The client gets a new "access token" for each grant request, and for each API call to the AS, and the client learns it can not make any more API calls for that specific request when it does not get an "access token" back. This is a completely different design pattern than calling an RS API with an access token, and is a new design pattern for calling APIs. This adds complexity to the client that it would not normally have, and I don't think GNAP is the right place to start a new design pattern. 4) Clients that only want claims from the AS and no access tokens will be required to support an API calling mechanism they would not have to support otherwise. 5) If the AS does not provide an "access token", there is no mechanism for a client to delete the request, as the client is not allowed to make a call without an "access token". 6) There is no standard identifier for the request. Debugging and auditing are hampered by the client and AS having no standard way to identifying a request. While one AS may provide a unique URL for each grant request, another AS may use a persistent "access token" to identify the grant request, and other ASs may issue a new "access token" on each API call, providing no persistent identifier for the request. Representing each grant request with an unique URL has the following advantages: 1) It follows the common REST like API model where each resource has a URI which is well understood. 2) There is only one way for a client and AS to identify a grant request. 3) There is a standard, persistent unique identifier for the client and AS to refer to a grant request. FWIW: the statement that it is more "access token" like than a cookie because it is bound to a key is untrue. Binding cookies to keys was the motivation for RFC 8471 - The Token Binding Protocol Version 1.0. Having the "access token" bound to a key provides no value as the AS already knows which client it is through client authentication. The only time that would not be the case is if the "access token" was self contained and the grant request APIs were at an server independent of the AS where the original request was made. =E1=90=A7 On Mon, Nov 23, 2020 at 9:55 AM Justin Richer wrote: > An important distinction here is that the access tokens in question are > always going to be bound to a key for presentation purposes, so in many > ways they are quite distinct from cookies. > > Since =E2=80=9Ccontinuation=E2=80=9D in its various forms is now an API, = why not treat it > like other APIs the client would call and use access tokens? > > Apart from design choices, what is the negative cost of requiring an > access token? > > We aren=E2=80=99t asking the client to do anything it=E2=80=99s not alrea= dy doing. Even if > the client is going to use bearer tokens at a downstream RS, the signatur= e > presentation mechanism for the bound access token at the continuation API > is exactly the same as what the client used in the first place to get the > continuation response. > > We aren=E2=80=99t asking the AS to do anything special either since it al= ready > needs to be able to validate the signature inbound, and it needs to be ab= le > to reference an artifact for the ongoing request (stateful or not). > > =E2=80=94 Justin > > On Nov 23, 2020, at 12:44 PM, Fabien Imbault > wrote: > > Yes. "Cookies were designed to be a reliable mechanism for websites to > remember stateful informati= on". > We're not storing anything, it's just a reference. > > On Mon, Nov 23, 2020 at 6:38 PM Dick Hardt wrote: > >> To clarify, I am talking about HTTP cookies, which are effectively opaqu= e >> to the web browser, and used by the web server to store state. >> >> https://en.wikipedia.org/wiki/HTTP_cookie >> >> A client may use local storage for saving state, but that is completely >> different from an HTTP cookie which is issued by the server. >> =E1=90=A7 >> >> On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault >> wrote: >> >>> If the client was directly managing/storing its state, then it would >>> indeed effectively work as a cookie. >>> But here the access token merely provides a map to the current state >>> (opaque to the client), as managed/controlled by the AS. >>> It's a very different use case compared to what cookies are used for in >>> webapps. >>> >>> Having a unique URL is a different design (XAuth was more aligned with >>> that idea). >>> >>> Fabien >>> >>> >>> On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt wrote= : >>> >>>> If all the access token is doing is expressing "please continue" ... >>>> why do we need an access token? >>>> >>>> Why not just have a unique URL for the grant request? The URL is the >>>> identifier for the grant request that allows the client to delete, upd= ate, >>>> etc. >>>> >>>> How the access token is being used is just like a cookie. The AS gives >>>> a string to the client and the client must pass the string back to the= AS >>>> when it calls it, the AS may then give a new string to the client for = the >>>> next call. Works like a cookie. I don't know why you think there are l= egal >>>> issues around this. >>>> >>>> /Dick >>>> >>>> >>>> >>>> =E1=90=A7 >>>> >>>> On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Dick, >>>>> >>>>> In GNAP, the client isn't managing state (unlike a web app), the >>>>> entire point is that the lifecycle should be managed by the AS. >>>>> >>>>> As in any state machine, there are states and transitions. Here we're >>>>> not passing state, merely expressing "please continue". The client ca= n be >>>>> completely unaware of the underlying state. >>>>> In effect the client only has the ability to ask the server to >>>>> generate the next transition. >>>>> >>>>> So I don't think you can compare that to cookies. It's a different >>>>> behavior. BTW if it was the case it would lead to a whole new class o= f >>>>> issues, because there's an entire legal framework around cookies... >>>>> >>>>> To avoid confusion with a standard access token, we have the "key" >>>>> field. My proposal would be to make it more explicitly (cf comment in= issue >>>>> 67). >>>>> >>>>> Fabien >>>>> >>>>> >>>>> Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt = a >>>>> =C3=A9crit : >>>>> >>>>>> When I look at how GNAP is using access tokens for continuation >>>>>> requests, and the pull request #129 >>>>>> >>>>>> >>>>>> Those "access tokens" look a lot more like cookies (managing state) >>>>>> than how access tokens are usually used (representing authorization)= . See >>>>>> table below. >>>>>> >>>>>> If there is a real requirement for passing state back and forth >>>>>> between a server (the AS in this case) and the client when making AP= I >>>>>> calls, then I suggest that is out of scope for GNAP as I see it bein= g a >>>>>> general purpose mechanism for any API. >>>>>> >>>>>> /Dick >>>>>> >>>>>> >>>>>> >>>>>> *cookies*- issued by server being accessed >>>>>> - are not presented to other servers >>>>>> - issued after first access >>>>>> - may be different for different URLs >>>>>> - may be updated on each access >>>>>> - represents the context of a session (state) >>>>>> >>>>>> >>>>>> *access tokens*- issued by an independent service (AS) >>>>>> - may be used at any URL at the RS >>>>>> - new ones issued by AS as needed >>>>>> - represents authorization granted to a client at an RS >>>>>> =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 > > > --00000000000060fa2f05b4f44184 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

There are numerous issues with the pro= posal:

1) It is not an "access token". J= ust because=C2=A0it is sent in the HTTP Authorization header does not make = it an access token. The client has already authenticated before the "a= ccess token" is presented. The AS already knows what the client is aut= horized to do at the AS before the "access token" is issued, so i= t is not=C2=A0needed to represent authorization as an access token is with = an RS. The "access token" is serving the purpose that the transac= tion handle=C2=A0served in the past --=C2=A0the context of the transaction.= Per my earlier comments, this "access token" is more like a cook= ie.

2) Calling it an "access token" is c= hanging=C2=A0the well known meaning of an access token as used in OAuth. Th= e client authenticates to the AS APIs in OAuth 2.0, it does not present an = access token. Access tokens are presented by a client to an RS to prove aut= horization.=C2=A0

3) What the client has to do wit= h the "access token" is not the same as access tokens for an RS. = The client gets a new "access token" for each grant request, and = for each API call to the AS, and the client learns it can not make any more= API calls for that specific request when it does not get an "access t= oken" back. This is a completely different design pattern than calling= an RS API with an access token,=C2=A0and is a new design pattern for calli= ng APIs. This adds complexity to the client that it would not normally have= , and I don't think GNAP is the right place to start a new design patte= rn.

4) Clients that only want claims from the AS a= nd no access tokens will be required to support an API calling mechanism th= ey would not have to support otherwise.=C2=A0

5) I= f the AS does not provide an "access token", there is no mechanis= m for a client to delete the request, as the client is not allowed to make = a call without an "access token".

6) The= re is no standard identifier for the request. Debugging and auditing are ha= mpered by the client and AS having no standard way to identifying a request= . While one AS may provide a unique URL for each grant request, another AS = may use a persistent "access token" to identify the grant request= , and other ASs may=C2=A0issue a new "access token" on each API c= all, providing no persistent identifier for the request.

Representing each grant request with an unique URL has the following= advantages:

1) It follows the common REST like AP= I model where each resource has a URI which is well understood.
<= br>
2) There is only one way for a client and AS to identify a gr= ant request.

3) There is a standard, persistent un= ique identifier for the client and AS to refer to a grant request.


FWIW: the statement that it is more "a= ccess token" like than a cookie because it is bound to a key is untrue= . Binding cookies to keys was the motivation for RFC 8471 - The Token Bindi= ng Protocol Version 1.0. Having the "access token" bound to a key= provides no value as the AS already knows which client it is through clien= t authentication. The only time that would not be the case is if the "= access token" was self contained and the grant request APIs were at an= server independent=C2=A0of the AS where the original request was made.=C2= =A0




=
3D""=E1=90=A7

On Mon, Nov 23, 2020 at 9:55 AM Justin Richer <= jricher@mit.edu>= ; wrote:
An important distinction here is that the access tokens in question are = always going to be bound to a key for presentation purposes, so in many way= s they are quite distinct from cookies.

Since =E2= =80=9Ccontinuation=E2=80=9D in its various forms is now an API, why not tre= at it like other APIs the client would call and use access tokens?

Apart from design choices, what is the negative cost of re= quiring an access token?

We aren=E2=80=99t asking = the client to do anything it=E2=80=99s not already doing. Even if the clien= t is going to use bearer tokens at a downstream RS, the signature presentat= ion mechanism for the bound access token at the continuation API is exactly= the same as what the client used in the first place to get the continuatio= n response.=C2=A0

We aren=E2=80=99t asking the AS = to do anything special either since it already needs to be able to validate= the signature inbound, and it needs to be able to reference an artifact fo= r the ongoing request (stateful or not).=C2=A0

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

On Nov 23,= 2020, at 12:44 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

=
Yes. "Cookies were designed to be a reliable mech= anism for websites to remember=C2=A0stateful=C2=A0information". We're not storing anyth= ing, it's just a reference.=C2=A0

On Mon, Nov 23, 2020 at 6:38 PM= Dick Hardt <d= ick.hardt@gmail.com> wrote:
To clarify, I am talking about HTT= P cookies, which are effectively opaque to the web browser,=C2=A0and used b= y the web server to store state.


A client may use loc= al storage for saving=C2=A0state, but that is completely different from an = HTTP cookie which is issued by the server.
3D""=E1=90= =A7

On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
If the client was directly managing/sto= ring its state, then it would indeed effectively work as a cookie.=C2=A0
But here the access token merely provides a map to the current = state (opaque to the client), as managed/controlled by the AS.=C2=A0
It's a very different use case compared to what cookies are use= d for in webapps.=C2=A0

Having a unique URL is a d= ifferent design (XAuth was more aligned with that idea).=C2=A0
Fabien
=C2=A0=C2=A0

On Mon, Nov 23, 2020 at 5:0= 9 PM Dick Hardt <dick.hardt@gmail.com> wrote:
If all the access token is doing is= expressing "please continue" ... why do we need an access token?=

Why not just have a unique=C2=A0URL for the grant reque= st? The URL is the identifier for the grant request that allows the client = to delete, update, etc.

How the access token is be= ing used is just like a cookie. The AS gives a string to the client and the= client must pass the string back to the AS when it calls it,=C2=A0the AS m= ay then give a new string=C2=A0to the client for the next call. Works like = a cookie. I don't know why you think there are legal issues around this= .=C2=A0

/Dick


<= div>
3D""= =E1=90=A7

On Sun, Nov 22, 2020 at = 11:40 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Dick,

In GNAP, the client isn't managin= g state (unlike a web app), the entire point is that the lifecycle should b= e managed by the AS.=C2=A0

As in any state machine, there are states and transitions. Here we'r= e not passing state, merely expressing "please continue". The cli= ent can be completely unaware of the underlying state.=C2=A0
In effect the client only = has the ability to ask the server to generate the next transition.

So I don't think = you can compare that to cookies. It's a different behavior. BTW if it w= as the case it would lead to a whole new class of issues, because there'= ;s an entire legal framework around cookies...=C2=A0

To avoid confusion with a standard access toke= n, we have the "key" field. My proposal would be to make it more = explicitly (cf comment in issue 67).

Fabien=C2=A0


Le lun. 23 nov. 2020 =C3=A0 02:06= , Dick Hardt <= dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
When I look at how G= NAP is using access tokens for continuation requests, and the pull request= =C2=A0#129

Those "= access tokens" look a lot more like cookies (managing state) than how = access tokens are usually used (representing authorization). See table belo= w.

If there is a real requirement for passing stat= e back and forth between a server (the AS in this case) and the client when= making API calls, then I suggest that is out of scope for GNAP as I see it= being a general=C2=A0purpose mechanism for any API.

/Dick


cookies
- issued by server = being accessed
- are not presented to other servers
- issued after fi= rst access
- may be different for different URLs
- may be updated on = each access
- represents the context of a session (state)

acce= ss tokens
- issued by an independent service (AS)
- may be used a= t any URL at the RS
- new ones issued by AS as needed
- represents au= thorization granted to a client at an RS
3D""=E1= =90=A7
--
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=

--00000000000060fa2f05b4f44184-- From nobody Wed Nov 25 12:33: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 ADFEF3A1CA0 for ; Wed, 25 Nov 2020 12:33:51 -0800 (PST) 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 zPLOBwNRZqgp for ; Wed, 25 Nov 2020 12:33:49 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FBB3A1C9D for ; Wed, 25 Nov 2020 12:33:49 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id r17so3301663ilo.11 for ; Wed, 25 Nov 2020 12:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VQcjGU9md19yRk2vrBiaj+znUXp8lF00XV1HN6sK86I=; b=UM/B1348ngN0Q7/s41dJ3xpehEZxcgBIN/l+u9ZUaMQkSYqIdGWyPRhHmLBP147fvO JNY6mW4kXBqZrGPQXH3X/6YIKLtXf7eKeZnwrmqfuqX1drtms/BntyRBqbpngfbFbpo4 5Xhj9xWBfccaQHXiuVz3JH1KEMl9Ig7Y8rTHrWkIe3FiNwnaFGUSPdMsCabrrQJk9Ipi 68Iia3fs6zeii8No7eu0YIu1m21VGGWZtq1nx7nFNG3me9erpDtDu/NqBHCMnt8qKmu6 xNCSDT/KkxzfFMbzvK1gh9MQal5cH0YoQK/t0l+9Jg0OCt6tWsxin4H1nkA7s6UPgIvL FBZQ== 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=VQcjGU9md19yRk2vrBiaj+znUXp8lF00XV1HN6sK86I=; b=ZVfvUrC04Ko1J2BMDDMyclDQ3c5hn2YfHSAnbRlF/sWDus2iPnZwCDlrSHsNgC+3yj 6lS5XycOgu54ON//ba/ddcJ0rLsf5RlyRax1vUHNUaPfqph/A5Zi56/1LIso6E7My0GV k4oThVqZo87Ya0WWZjSlNv4lW8lS56xZP0tfXBkCMffnNFwprshm6gpPzY/qataiY3Oq qwVk07Z3GGDains5wvopL4ri+nFEX2X2smUfx1iS9jgsaQuLYVpDFeLbiNvTVFxjPjVU AshhGgsRULJzBg0vq36K9ALNwp2Ly6LG3kBkC0TOTwCU/UOs8eUaMhNrxEpDMMuCB/VT RcWA== X-Gm-Message-State: AOAM531Dp3TWeJ8lhmoVrqcCqz/PJon44GeEh1Myc3lo13jvmePljlmL NCSRgXEDxBFjDLadxI8lesTRxPJ+mi254f7WkrU= X-Google-Smtp-Source: ABdhPJxMwPwlwd2ERWTiLxSaITj9Zg9JYr0UKRRTHqtbsZ1xrggTmOoceuOw679CquBrFuALUcatlgvMO8TvK6A7COs= X-Received: by 2002:a92:d80e:: with SMTP id y14mr4058086ilm.68.1606336428452; Wed, 25 Nov 2020 12:33:48 -0800 (PST) MIME-Version: 1.0 References: <9D3D60CC-5019-4CC2-BE2D-4EF789FABE31@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 25 Nov 2020 21:33:37 +0100 Message-ID: To: Dick Hardt Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000003531b105b4f458af" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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, 25 Nov 2020 20:33:52 -0000 --0000000000003531b105b4f458af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dick, There is more context on the rationale, from the comments the editors made to the issues yesterday. Especially the part on unique URLs. Best Fabien Le mer. 25 nov. 2020 =C3=A0 21:27, Dick Hardt a =C3= =A9crit : > > There are numerous issues with the proposal: > > 1) It is not an "access token". Just because it is sent in the HTTP > Authorization header does not make it an access token. The client has > already authenticated before the "access token" is presented. The AS > already knows what the client is authorized to do at the AS before the > "access token" is issued, so it is not needed to represent authorization = as > an access token is with an RS. The "access token" is serving the purpose > that the transaction handle served in the past -- the context of the > transaction. Per my earlier comments, this "access token" is more like a > cookie. > > 2) Calling it an "access token" is changing the well known meaning of an > access token as used in OAuth. The client authenticates to the AS APIs in > OAuth 2.0, it does not present an access token. Access tokens are present= ed > by a client to an RS to prove authorization. > > 3) What the client has to do with the "access token" is not the same as > access tokens for an RS. The client gets a new "access token" for each > grant request, and for each API call to the AS, and the client learns it > can not make any more API calls for that specific request when it does no= t > get an "access token" back. This is a completely different design pattern > than calling an RS API with an access token, and is a new design pattern > for calling APIs. This adds complexity to the client that it would not > normally have, and I don't think GNAP is the right place to start a new > design pattern. > > 4) Clients that only want claims from the AS and no access tokens will be > required to support an API calling mechanism they would not have to suppo= rt > otherwise. > > 5) If the AS does not provide an "access token", there is no mechanism fo= r > a client to delete the request, as the client is not allowed to make a ca= ll > without an "access token". > > 6) There is no standard identifier for the request. Debugging and auditin= g > are hampered by the client and AS having no standard way to identifying a > request. While one AS may provide a unique URL for each grant request, > another AS may use a persistent "access token" to identify the grant > request, and other ASs may issue a new "access token" on each API call, > providing no persistent identifier for the request. > > Representing each grant request with an unique URL has the following > advantages: > > 1) It follows the common REST like API model where each resource has a UR= I > which is well understood. > > 2) There is only one way for a client and AS to identify a grant request. > > 3) There is a standard, persistent unique identifier for the client and A= S > to refer to a grant request. > > > FWIW: the statement that it is more "access token" like than a cookie > because it is bound to a key is untrue. Binding cookies to keys was the > motivation for RFC 8471 - The Token Binding Protocol Version 1.0. Having > the "access token" bound to a key provides no value as the AS already kno= ws > which client it is through client authentication. The only time that woul= d > not be the case is if the "access token" was self contained and the grant > request APIs were at an server independent of the AS where the original > request was made. > > > > > =E1=90=A7 > > On Mon, Nov 23, 2020 at 9:55 AM Justin Richer wrote: > >> An important distinction here is that the access tokens in question are >> always going to be bound to a key for presentation purposes, so in many >> ways they are quite distinct from cookies. >> >> Since =E2=80=9Ccontinuation=E2=80=9D in its various forms is now an API,= why not treat it >> like other APIs the client would call and use access tokens? >> >> Apart from design choices, what is the negative cost of requiring an >> access token? >> >> We aren=E2=80=99t asking the client to do anything it=E2=80=99s not alre= ady doing. Even >> if the client is going to use bearer tokens at a downstream RS, the >> signature presentation mechanism for the bound access token at the >> continuation API is exactly the same as what the client used in the firs= t >> place to get the continuation response. >> >> We aren=E2=80=99t asking the AS to do anything special either since it a= lready >> needs to be able to validate the signature inbound, and it needs to be a= ble >> to reference an artifact for the ongoing request (stateful or not). >> >> =E2=80=94 Justin >> >> On Nov 23, 2020, at 12:44 PM, Fabien Imbault >> wrote: >> >> Yes. "Cookies were designed to be a reliable mechanism for websites to >> remember stateful informat= ion". >> We're not storing anything, it's just a reference. >> >> On Mon, Nov 23, 2020 at 6:38 PM Dick Hardt wrote: >> >>> To clarify, I am talking about HTTP cookies, which are effectively >>> opaque to the web browser, and used by the web server to store state. >>> >>> https://en.wikipedia.org/wiki/HTTP_cookie >>> >>> A client may use local storage for saving state, but that is completely >>> different from an HTTP cookie which is issued by the server. >>> =E1=90=A7 >>> >>> On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault >>> wrote: >>> >>>> If the client was directly managing/storing its state, then it would >>>> indeed effectively work as a cookie. >>>> But here the access token merely provides a map to the current state >>>> (opaque to the client), as managed/controlled by the AS. >>>> It's a very different use case compared to what cookies are used for i= n >>>> webapps. >>>> >>>> Having a unique URL is a different design (XAuth was more aligned with >>>> that idea). >>>> >>>> Fabien >>>> >>>> >>>> On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt >>>> wrote: >>>> >>>>> If all the access token is doing is expressing "please continue" ... >>>>> why do we need an access token? >>>>> >>>>> Why not just have a unique URL for the grant request? The URL is the >>>>> identifier for the grant request that allows the client to delete, up= date, >>>>> etc. >>>>> >>>>> How the access token is being used is just like a cookie. The AS give= s >>>>> a string to the client and the client must pass the string back to th= e AS >>>>> when it calls it, the AS may then give a new string to the client for= the >>>>> next call. Works like a cookie. I don't know why you think there are = legal >>>>> issues around this. >>>>> >>>>> /Dick >>>>> >>>>> >>>>> >>>>> =E1=90=A7 >>>>> >>>>> On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Dick, >>>>>> >>>>>> In GNAP, the client isn't managing state (unlike a web app), the >>>>>> entire point is that the lifecycle should be managed by the AS. >>>>>> >>>>>> As in any state machine, there are states and transitions. Here we'r= e >>>>>> not passing state, merely expressing "please continue". The client c= an be >>>>>> completely unaware of the underlying state. >>>>>> In effect the client only has the ability to ask the server to >>>>>> generate the next transition. >>>>>> >>>>>> So I don't think you can compare that to cookies. It's a different >>>>>> behavior. BTW if it was the case it would lead to a whole new class = of >>>>>> issues, because there's an entire legal framework around cookies... >>>>>> >>>>>> To avoid confusion with a standard access token, we have the "key" >>>>>> field. My proposal would be to make it more explicitly (cf comment i= n issue >>>>>> 67). >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt = a >>>>>> =C3=A9crit : >>>>>> >>>>>>> When I look at how GNAP is using access tokens for continuation >>>>>>> requests, and the pull request #129 >>>>>>> >>>>>>> >>>>>>> Those "access tokens" look a lot more like cookies (managing state) >>>>>>> than how access tokens are usually used (representing authorization= ). See >>>>>>> table below. >>>>>>> >>>>>>> If there is a real requirement for passing state back and forth >>>>>>> between a server (the AS in this case) and the client when making A= PI >>>>>>> calls, then I suggest that is out of scope for GNAP as I see it bei= ng a >>>>>>> general purpose mechanism for any API. >>>>>>> >>>>>>> /Dick >>>>>>> >>>>>>> >>>>>>> >>>>>>> *cookies*- issued by server being accessed >>>>>>> - are not presented to other servers >>>>>>> - issued after first access >>>>>>> - may be different for different URLs >>>>>>> - may be updated on each access >>>>>>> - represents the context of a session (state) >>>>>>> >>>>>>> >>>>>>> *access tokens*- issued by an independent service (AS) >>>>>>> - may be used at any URL at the RS >>>>>>> - new ones issued by AS as needed >>>>>>> - represents authorization granted to a client at an RS >>>>>>> =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 >> >> >> --0000000000003531b105b4f458af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,

The= re is more context on the rationale, from the comments the editors made to = the issues yesterday.=C2=A0

Especially the part on unique URLs.=C2=A0

Best=C2=A0
Fabien=C2=A0
<= br>
Le mer. 25 nov. 2020 =C3=A0 21:27, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:

There are numerous issues with the proposal:

1) I= t is not an "access token". Just because=C2=A0it is sent in the H= TTP Authorization header does not make it an access token. The client has a= lready authenticated before the "access token" is presented. The = AS already knows what the client is authorized to do at the AS before the &= quot;access token" is issued, so it is not=C2=A0needed to represent au= thorization as an access token is with an RS. The "access token" = is serving the purpose that the transaction handle=C2=A0served in the past = --=C2=A0the context of the transaction. Per my earlier comments, this "= ;access token" is more like a cookie.

2) Call= ing it an "access token" is changing=C2=A0the well known meaning = of an access token as used in OAuth. The client authenticates to the AS API= s in OAuth 2.0, it does not present an access token. Access tokens are pres= ented by a client to an RS to prove authorization.=C2=A0

3) What the client has to do with the "access token" is no= t the same as access tokens for an RS. The client gets a new "access t= oken" for each grant request, and for each API call to the AS, and the= client learns it can not make any more API calls for that specific request= when it does not get an "access token" back. This is a completel= y different design pattern than calling an RS API with an access token,=C2= =A0and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.

4) Cli= ents that only want claims from the AS and no access tokens will be require= d to support an API calling mechanism they would not have to support otherw= ise.=C2=A0

5) If the AS does not provide an "= access token", there is no mechanism for a client to delete the reques= t, as the client is not allowed to make a call without an "access toke= n".

6) There is no standard identifier for th= e request. Debugging and auditing are hampered by the client and AS having = no standard way to identifying a request. While one AS may provide a unique= URL for each grant request, another AS may use a persistent "access t= oken" to identify the grant request, and other ASs may=C2=A0issue a ne= w "access token" on each API call, providing no persistent identi= fier for the request.

Representing each grant requ= est with an unique URL has the following advantages:

1) It follows the common REST like API model where each resource has a U= RI which is well understood.

2) There is only one = way for a client and AS to identify a grant request.

3) There is a standard, persistent unique identifier for the client and = AS to refer to a grant request.


FWI= W: the statement that it is more "access token" like than a cooki= e because it is bound to a key is untrue. Binding cookies to keys was the m= otivation for RFC 8471 - The Token Binding Protocol Version 1.0. Having the= "access token" bound to a key provides no value as the AS alread= y knows which client it is through client authentication. The only time tha= t would not be the case is if the "access token" was self contain= ed and the grant request APIs were at an server independent=C2=A0of the AS = where the original request was made.=C2=A0




3D""=E1=90=A7

<= div class=3D"gmail_quote">
On Mon, Nov= 23, 2020 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
An important d= istinction here is that the access tokens in question are always going to b= e bound to a key for presentation purposes, so in many ways they are quite = distinct from cookies.

Since =E2=80=9Ccontinuation= =E2=80=9D in its various forms is now an API, why not treat it like other A= PIs the client would call and use access tokens?

A= part from design choices, what is the negative cost of requiring an access = token?

We aren=E2=80=99t asking the client to do a= nything it=E2=80=99s not already doing. Even if the client is going to use = bearer tokens at a downstream RS, the signature presentation mechanism for = the bound access token at the continuation API is exactly the same as what = the client used in the first place to get the continuation response.=C2=A0<= /div>

We aren=E2=80=99t asking the AS to do anything spe= cial either since it already needs to be able to validate the signature inb= ound, and it needs to be able to reference an artifact for the ongoing requ= est (stateful or not).=C2=A0

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

On Nov 23, 2020, at 12:44 PM= , Fabien Imbault <fabien.imbault@gmail.com> wrote:
Yes. "Cookies were designed to be a reliable mec= hanism for websites to remember=C2=A0stateful=C2=A0information". We'r= e not storing anything, it's just a reference.=C2=A0

On Mon, Nov = 23, 2020 at 6:38 PM Dick Hardt <dick.hardt@gmail.com> wrote:
<= div>To clarify, I am talking about HTTP cookies, which are effectively opaq= ue to the web browser,=C2=A0and used by the web server to store state.


A client may use local storage for sav= ing=C2=A0state, but that is completely different from an HTTP cookie which = is issued by the server.
3D""=E1=90=A7

On Mon, Nov 23= , 2020 at 8:30 AM Fabien Imbault <fabien.imbault@gmail.com>= wrote:
If the client was directly managing/storing = its state, then it would indeed effectively work as a cookie.=C2=A0
But here the access token merely provides a map to the current state= (opaque to the client), as managed/controlled by the AS.=C2=A0
It's a very different use case compared to what cookies are used for= in webapps.=C2=A0

Having a unique URL is a differ= ent design (XAuth was more aligned with that idea).=C2=A0

Fabien
=C2=A0=C2=A0

On Mon, Nov 23, 2020 at 5:09 PM = Dick Hardt <dick.hardt@gmail.com> wrote:
If all the access tok= en is doing is expressing "please continue" ... why do we need an= access token?

Why not just have a unique=C2=A0URL for t= he grant request? The URL is the identifier for the grant request that allo= ws the client to delete, update, etc.

How the acce= ss token is being used is just like a cookie. The AS gives a string to the = client and the client must pass the string back to the AS when it calls it,= =C2=A0the AS may then give a new string=C2=A0to the client for the next cal= l. Works like a cookie. I don't know why you think there are legal issu= es around this.=C2=A0

/Dick



3D""=E1=90=A7

On Sun, Nov 22, = 2020 at 11:40 PM Fabien Imbault <fabien.imbault@gmail.com> = wrote:
Hi Dick,

In GNAP, th= e client isn't managing state (unlike a web app), the entire point is t= hat the lifecycle should be managed by the AS.=C2=A0

As in any state machine, there are states and = transitions. Here we're not passing state, merely expressing "plea= se continue". The client can be completely unaware of the underlying s= tate.=C2=A0
I= n effect the client only has the ability to ask the server to generate the = next transition.

So I don't think you can compare that to cookies. It's a differ= ent behavior. BTW if it was the case it would lead to a whole new class of = issues, because there's an entire legal framework around cookies...=C2= =A0

To avoid confusion w= ith a standard access token, we have the "key" field. My proposal= would be to make it more explicitly (cf comment in issue 67).

Fabien=C2=A0


Le lun.= 23 nov. 2020 =C3=A0 02:06, Dick Hardt <dick.hardt@gmail.com> a= =C3=A9crit=C2=A0:
When I look at how GNAP is using access tokens for= continuation requests, and the pull request=C2=A0#129

Those "access tokens" = look a lot more like cookies (managing state) than how access tokens are us= ually used (representing authorization). See table below.

If there is a real requirement for passing state back and forth bet= ween a server (the AS in this case) and the client when making API calls, t= hen I suggest that is out of scope for GNAP as I see it being a general=C2= =A0purpose mechanism for any API.

/Dick

<= div>
cookies
- issued by server being accessed
-= are not presented to other servers
- issued after first access
- may= be different for different URLs
- may be updated on each access
- re= presents the context of a session (state)

access tokens
- = issued by an independent service (AS)
- may be used at any URL at the RS=
- new ones issued by AS as needed
- represents authorization granted= to a client at an RS
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https:= //www.ietf.org/mailman/listinfo/txauth

= --0000000000003531b105b4f458af-- From nobody Wed Nov 25 12:37: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 0CAE13A1CB6 for ; Wed, 25 Nov 2020 12:37:42 -0800 (PST) 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 1sMwR_i73NGg for ; Wed, 25 Nov 2020 12:37:39 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450: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 18BD73A1CAA for ; Wed, 25 Nov 2020 12:37:35 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id s27so4978629lfp.5 for ; Wed, 25 Nov 2020 12:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3qtCwpBwqHv0zeXiuMBvJimAM3Abeg6/JXDhZOXCtLA=; b=myz0+mcuqX70l5pcAbnyEdRmjJmnNootsTdn++hqHtano0C+qDGn6sZ9Xon0pHpxZW cVdV02vCYJxXOhQyrHDc6gTKpmdOdOFVoAIzwvRijWd8sqhE4FcY16CiVE3YssydE3bz vEoFH4y/c3Ac2bmKjyOyMvpvIJ12QwqoSYW2CXZ7TzIurvheL3N3wrxaB+otbJv7Ahhe 7hpf9qMawYCzzWvrUTTbHKMub3wmEa5BLaCFYLsK5B/g0DpBYJCRAmLtfhvAnSspMsVS lcPKFEomfI51MKzn36jkQGxU+UrWwD41SHEvzf7e5qKRrZhr6Q4VcYtVThZO7GrdfyJx a+Mw== 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=3qtCwpBwqHv0zeXiuMBvJimAM3Abeg6/JXDhZOXCtLA=; b=jrmb3HkTI98qNRhcKCV7XwDGgn/7c+P4b3x9/xb+EghE3hI/f2Ipy0k/HbnzpYFQDh 5xC1NG02M2zcN6cK2I1iutntkFw1sjSYFjS5y1k4lJwg7EExJl9+gKQJ8XpmqSD+ZSLB vlEGG5Nx/FwhktQGR7ffB2mYfR+xaIpDmZM9F05SQu+OtNfWR+/5LsQOpOfq+WeT4QE0 9UoxSv9nKSOk6UdwoQrmwqHmPGOE/09/nid8jjOPk9h9Q5SvkeSr8td2lkzY0EnPM9Yy 9VtZd1tewJR9K6rb6t/3sbu7RuLXd0AFFUOXlw1NW8Ns8faFDEYekHDgfRm9lyAW2g7p uw+g== X-Gm-Message-State: AOAM531YjFtzjN8LjcvgNo8QI8szb29TMtUdO++bP18YgPx2HbmOMJZJ DqZKjdqMDZDtfkCTrCXHZDmsMYp3m5jptrPIK40= X-Google-Smtp-Source: ABdhPJy8ZLobH7WXy6yY7dhCEnCQhhQm5J6F9JzlpEr8JOQZZPxdAtNkhU2icWceuoclfD495GEzUSsq4Vh15Cv2Kx0= X-Received: by 2002:a05:6512:3047:: with SMTP id b7mr243274lfb.210.1606336653063; Wed, 25 Nov 2020 12:37:33 -0800 (PST) MIME-Version: 1.0 References: <9D3D60CC-5019-4CC2-BE2D-4EF789FABE31@mit.edu> In-Reply-To: From: Dick Hardt Date: Wed, 25 Nov 2020 12:36:56 -0800 Message-ID: To: Fabien Imbault Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000098843805b4f4657c" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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, 25 Nov 2020 20:37:42 -0000 --00000000000098843805b4f4657c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Would you share a link? I see the discussion on the access token pull request, but no discussion on unique URLs. Do you agree with my assessment of the "access token"? =E1=90=A7 On Wed, Nov 25, 2020 at 12:33 PM Fabien Imbault wrote: > Hi Dick, > > There is more context on the rationale, from the comments the editors mad= e > to the issues yesterday. > > Especially the part on unique URLs. > > Best > Fabien > > > Le mer. 25 nov. 2020 =C3=A0 21:27, Dick Hardt a = =C3=A9crit : > >> >> There are numerous issues with the proposal: >> >> 1) It is not an "access token". Just because it is sent in the HTTP >> Authorization header does not make it an access token. The client has >> already authenticated before the "access token" is presented. The AS >> already knows what the client is authorized to do at the AS before the >> "access token" is issued, so it is not needed to represent authorization= as >> an access token is with an RS. The "access token" is serving the purpose >> that the transaction handle served in the past -- the context of the >> transaction. Per my earlier comments, this "access token" is more like a >> cookie. >> >> 2) Calling it an "access token" is changing the well known meaning of an >> access token as used in OAuth. The client authenticates to the AS APIs i= n >> OAuth 2.0, it does not present an access token. Access tokens are presen= ted >> by a client to an RS to prove authorization. >> >> 3) What the client has to do with the "access token" is not the same as >> access tokens for an RS. The client gets a new "access token" for each >> grant request, and for each API call to the AS, and the client learns it >> can not make any more API calls for that specific request when it does n= ot >> get an "access token" back. This is a completely different design patter= n >> than calling an RS API with an access token, and is a new design pattern >> for calling APIs. This adds complexity to the client that it would not >> normally have, and I don't think GNAP is the right place to start a new >> design pattern. >> >> 4) Clients that only want claims from the AS and no access tokens will b= e >> required to support an API calling mechanism they would not have to supp= ort >> otherwise. >> >> 5) If the AS does not provide an "access token", there is no mechanism >> for a client to delete the request, as the client is not allowed to make= a >> call without an "access token". >> >> 6) There is no standard identifier for the request. Debugging and >> auditing are hampered by the client and AS having no standard way to >> identifying a request. While one AS may provide a unique URL for each gr= ant >> request, another AS may use a persistent "access token" to identify the >> grant request, and other ASs may issue a new "access token" on each API >> call, providing no persistent identifier for the request. >> >> Representing each grant request with an unique URL has the following >> advantages: >> >> 1) It follows the common REST like API model where each resource has a >> URI which is well understood. >> >> 2) There is only one way for a client and AS to identify a grant request= . >> >> 3) There is a standard, persistent unique identifier for the client and >> AS to refer to a grant request. >> >> >> FWIW: the statement that it is more "access token" like than a cookie >> because it is bound to a key is untrue. Binding cookies to keys was the >> motivation for RFC 8471 - The Token Binding Protocol Version 1.0. Having >> the "access token" bound to a key provides no value as the AS already kn= ows >> which client it is through client authentication. The only time that wou= ld >> not be the case is if the "access token" was self contained and the gran= t >> request APIs were at an server independent of the AS where the original >> request was made. >> >> >> >> >> =E1=90=A7 >> >> On Mon, Nov 23, 2020 at 9:55 AM Justin Richer wrote: >> >>> An important distinction here is that the access tokens in question are >>> always going to be bound to a key for presentation purposes, so in many >>> ways they are quite distinct from cookies. >>> >>> Since =E2=80=9Ccontinuation=E2=80=9D in its various forms is now an API= , why not treat >>> it like other APIs the client would call and use access tokens? >>> >>> Apart from design choices, what is the negative cost of requiring an >>> access token? >>> >>> We aren=E2=80=99t asking the client to do anything it=E2=80=99s not alr= eady doing. Even >>> if the client is going to use bearer tokens at a downstream RS, the >>> signature presentation mechanism for the bound access token at the >>> continuation API is exactly the same as what the client used in the fir= st >>> place to get the continuation response. >>> >>> We aren=E2=80=99t asking the AS to do anything special either since it = already >>> needs to be able to validate the signature inbound, and it needs to be = able >>> to reference an artifact for the ongoing request (stateful or not). >>> >>> =E2=80=94 Justin >>> >>> On Nov 23, 2020, at 12:44 PM, Fabien Imbault >>> wrote: >>> >>> Yes. "Cookies were designed to be a reliable mechanism for websites to >>> remember stateful informa= tion". >>> We're not storing anything, it's just a reference. >>> >>> On Mon, Nov 23, 2020 at 6:38 PM Dick Hardt wrote= : >>> >>>> To clarify, I am talking about HTTP cookies, which are effectively >>>> opaque to the web browser, and used by the web server to store state. >>>> >>>> https://en.wikipedia.org/wiki/HTTP_cookie >>>> >>>> A client may use local storage for saving state, but that is completel= y >>>> different from an HTTP cookie which is issued by the server. >>>> =E1=90=A7 >>>> >>>> On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> If the client was directly managing/storing its state, then it would >>>>> indeed effectively work as a cookie. >>>>> But here the access token merely provides a map to the current state >>>>> (opaque to the client), as managed/controlled by the AS. >>>>> It's a very different use case compared to what cookies are used for >>>>> in webapps. >>>>> >>>>> Having a unique URL is a different design (XAuth was more aligned wit= h >>>>> that idea). >>>>> >>>>> Fabien >>>>> >>>>> >>>>> On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt >>>>> wrote: >>>>> >>>>>> If all the access token is doing is expressing "please continue" ... >>>>>> why do we need an access token? >>>>>> >>>>>> Why not just have a unique URL for the grant request? The URL is the >>>>>> identifier for the grant request that allows the client to delete, u= pdate, >>>>>> etc. >>>>>> >>>>>> How the access token is being used is just like a cookie. The AS >>>>>> gives a string to the client and the client must pass the string bac= k to >>>>>> the AS when it calls it, the AS may then give a new string to the cl= ient >>>>>> for the next call. Works like a cookie. I don't know why you think t= here >>>>>> are legal issues around this. >>>>>> >>>>>> /Dick >>>>>> >>>>>> >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Dick, >>>>>>> >>>>>>> In GNAP, the client isn't managing state (unlike a web app), the >>>>>>> entire point is that the lifecycle should be managed by the AS. >>>>>>> >>>>>>> As in any state machine, there are states and transitions. Here >>>>>>> we're not passing state, merely expressing "please continue". The c= lient >>>>>>> can be completely unaware of the underlying state. >>>>>>> In effect the client only has the ability to ask the server to >>>>>>> generate the next transition. >>>>>>> >>>>>>> So I don't think you can compare that to cookies. It's a different >>>>>>> behavior. BTW if it was the case it would lead to a whole new class= of >>>>>>> issues, because there's an entire legal framework around cookies... >>>>>>> >>>>>>> To avoid confusion with a standard access token, we have the "key" >>>>>>> field. My proposal would be to make it more explicitly (cf comment = in issue >>>>>>> 67). >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt a >>>>>>> =C3=A9crit : >>>>>>> >>>>>>>> When I look at how GNAP is using access tokens for continuation >>>>>>>> requests, and the pull request #129 >>>>>>>> >>>>>>>> >>>>>>>> Those "access tokens" look a lot more like cookies (managing state= ) >>>>>>>> than how access tokens are usually used (representing authorizatio= n). See >>>>>>>> table below. >>>>>>>> >>>>>>>> If there is a real requirement for passing state back and forth >>>>>>>> between a server (the AS in this case) and the client when making = API >>>>>>>> calls, then I suggest that is out of scope for GNAP as I see it be= ing a >>>>>>>> general purpose mechanism for any API. >>>>>>>> >>>>>>>> /Dick >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *cookies*- issued by server being accessed >>>>>>>> - are not presented to other servers >>>>>>>> - issued after first access >>>>>>>> - may be different for different URLs >>>>>>>> - may be updated on each access >>>>>>>> - represents the context of a session (state) >>>>>>>> >>>>>>>> >>>>>>>> *access tokens*- issued by an independent service (AS) >>>>>>>> - may be used at any URL at the RS >>>>>>>> - new ones issued by AS as needed >>>>>>>> - represents authorization granted to a client at an RS >>>>>>>> =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 >>> >>> >>> --00000000000098843805b4f4657c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would you share a link? I see the discussion on the access= token pull request, but no discussion on unique URLs.

D= o you agree with my assessment of the "access token"?
<= br>
=E1=90=A7

On Wed, Nov 25, 2020 at 12:33 PM Fa= bien Imbault <fabien.imbault= @gmail.com> wrote:
Hi Dick,

There is more context on the rationale, from the comments the edi= tors made to the issues yesterday.=C2=A0

<= div dir=3D"auto">Especially the part on unique URLs.=C2=A0

Best=C2=A0
Fabien= =C2=A0


Le mer. 25 nov. 2020 =C3=A0 21:27, Dick Hardt <dick.hardt@gmail.co= m> a =C3=A9crit=C2=A0:

There are numerous issue= s with the proposal:

1) It is not an "access = token". Just because=C2=A0it is sent in the HTTP Authorization header = does not make it an access token. The client has already authenticated befo= re the "access token" is presented. The AS already knows what the= client is authorized to do at the AS before the "access token" i= s issued, so it is not=C2=A0needed to represent authorization as an access = token is with an RS. The "access token" is serving the purpose th= at the transaction handle=C2=A0served in the past --=C2=A0the context of th= e transaction. Per my earlier comments, this "access token" is mo= re like a cookie.

2) Calling it an "access to= ken" is changing=C2=A0the well known meaning of an access token as use= d in OAuth. The client authenticates to the AS APIs in OAuth 2.0, it does n= ot present an access token. Access tokens are presented by a client to an R= S to prove authorization.=C2=A0

3) What the client= has to do with the "access token" is not the same as access toke= ns for an RS. The client gets a new "access token" for each grant= request, and for each API call to the AS, and the client learns it can not= make any more API calls for that specific request when it does not get an = "access token" back. This is a completely different design patter= n than calling an RS API with an access token,=C2=A0and is a new design pat= tern for calling APIs. This adds complexity to the client that it would not= normally have, and I don't think GNAP is the right place to start a ne= w design pattern.

4) Clients that only want claims= from the AS and no access tokens will be required to support an API callin= g mechanism they would not have to support otherwise.=C2=A0

<= /div>
5) If the AS does not provide an "access token", there = is no mechanism for a client to delete the request, as the client is not al= lowed to make a call without an "access token".

6) There is no standard identifier for the request. Debugging and a= uditing are hampered by the client and AS having no standard way to identif= ying a request. While one AS may provide a unique URL for each grant reques= t, another AS may use a persistent "access token" to identify the= grant request, and other ASs may=C2=A0issue a new "access token"= on each API call, providing no persistent identifier for the request.

Representing each grant request with an unique URL has= the following advantages:

1) It follows the commo= n REST like API model where each resource has a URI which is well understoo= d.

2) There is only one way for a client and AS to= identify a grant request.

3) There is a standard,= persistent unique identifier for the client and AS to refer to a grant req= uest.


FWIW: the statement that it i= s more "access token" like than a cookie because it is bound to a= key is untrue. Binding cookies to keys was the motivation for RFC 8471 - T= he Token Binding Protocol Version 1.0. Having the "access token" = bound to a key provides no value as the AS already knows which client it is= through client authentication. The only time that would not be the case is= if the "access token" was self contained and the grant request A= PIs were at an server independent=C2=A0of the AS where the original request= was made.=C2=A0



=E1=90=A7

On Mon, Nov 23, 2020 at 9:55 AM= Justin Richer <jricher@mit.edu> wrote:
An important distinction here is= that the access tokens in question are always going to be bound to a key f= or presentation purposes, so in many ways they are quite distinct from cook= ies.

Since =E2=80=9Ccontinuation=E2=80=9D in its v= arious forms is now an API, why not treat it like other APIs the client wou= ld call and use access tokens?

Apart from design c= hoices, what is the negative cost of requiring an access token?
<= br>
We aren=E2=80=99t asking the client to do anything it=E2=80= =99s not already doing. Even if the client is going to use bearer tokens at= a downstream RS, the signature presentation mechanism for the bound access= token at the continuation API is exactly the same as what the client used = in the first place to get the continuation response.=C2=A0

We aren=E2=80=99t asking the AS to do anything special either sinc= e it already needs to be able to validate the signature inbound, and it nee= ds to be able to reference an artifact for the ongoing request (stateful or= not).=C2=A0

=C2=A0=E2=80=94 Justin

=
On Nov 23, 2020, at 12:44 PM, Fabien Imbault= <fabien.imbault@gmail.com> wrote:

Yes. "Cookies were designed to be a reliable mechanism for web= sites to remember=C2=A0stateful=C2=A0information". We're not storing a= nything, it's just a reference.=C2=A0

On Mon, Nov 23, 2020 at 6:3= 8 PM Dick Hardt <dick.hardt@gmail.com> wrote:
To clarify,= I am talking about HTTP cookies, which are effectively opaque to the web b= rowser,=C2=A0and used by the web server to store state.

https://en.wikipedia.org/wiki/HTTP_cookie

A client may use local storage for saving=C2=A0state,= but that is completely different from an HTTP cookie which is issued by th= e server.
3D""=E1=90=A7

On Mon, Nov 23, 2020 at= 8:30 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
=
If the client was directly managing/storing its state= , then it would indeed effectively work as a cookie.=C2=A0
Bu= t here the access token merely provides a map to the current state (opaque = to the client), as managed/controlled by the AS.=C2=A0
It'= ;s a very different use case compared to what cookies are used for in webap= ps.=C2=A0

Having a unique URL is a different desig= n (XAuth was more aligned with that idea).=C2=A0

F= abien
=C2=A0=C2=A0

On Mon, Nov 23, 2020 at 5:09 PM Dick Hard= t <dick.hardt@gmail.com> wrote:
If all the access token is doi= ng is expressing "please continue" ... why do we need an access t= oken?

Why not just have a unique=C2=A0URL for the grant = request? The URL is the identifier for the grant request that allows the cl= ient to delete, update, etc.

How the access token = is being used is just like a cookie. The AS gives a string to the client an= d the client must pass the string back to the AS when it calls it,=C2=A0the= AS may then give a new string=C2=A0to the client for the next call. Works = like a cookie. I don't know why you think there are legal issues around= this.=C2=A0

/Dick



3D""=E1=90=A7

On Sun, Nov 22, 202= 0 at 11:40 PM Fabien Imbault <fabien.imbault@gmail.com> wro= te:
Hi Dick,

In GNAP, the cl= ient isn't managing state (unlike a web app), the entire point is that = the lifecycle should be managed by the AS.=C2=A0
As in any state machine, there are states and tran= sitions. Here we're not passing state, merely expressing "please c= ontinue". The client can be completely unaware of the underlying state= .=C2=A0
In ef= fect the client only has the ability to ask the server to generate the next= transition.

= So I don't think you can compare that to cookies. It's a different = behavior. BTW if it was the case it would lead to a whole new class of issu= es, because there's an entire legal framework around cookies...=C2=A0

To avoid confusion with a= standard access token, we have the "key" field. My proposal woul= d be to make it more explicitly (cf comment in issue 67).

Fabien=C2=A0


Le lun. 23 n= ov. 2020 =C3=A0 02:06, Dick Hardt <dick.hardt@gmail.com> a =C3= =A9crit=C2=A0:
<= div dir=3D"ltr">
When I look at how GNAP is using access tokens for con= tinuation requests, and the pull request=C2=A0#129

Those "access tokens" look= a lot more like cookies (managing state) than how access tokens are usuall= y used (representing authorization). See table below.

<= div>If there is a real requirement for passing state back and forth between= a server (the AS in this case) and the client when making API calls, then = I suggest that is out of scope for GNAP as I see it being a general=C2=A0pu= rpose mechanism for any API.

/Dick

<= br>
cookies
- issued by server being accessed
- are = not presented to other servers
- issued after first access
- may be d= ifferent for different URLs
- may be updated on each access
- represe= nts the context of a session (state)

access tokens
- issue= d by an independent service (AS)
- may be used at any URL at the RS
-= new ones issued by AS as needed
- represents authorization granted to a= client at an RS
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https:= //www.ietf.org/mailman/listinfo/txauth

=
--00000000000098843805b4f4657c-- From nobody Wed Nov 25 12:43: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 4727C3A1CBF for ; Wed, 25 Nov 2020 12:43:40 -0800 (PST) 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 mVVxJDEAUDOy for ; Wed, 25 Nov 2020 12:43:37 -0800 (PST) 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 C46BF3A1CBE for ; Wed, 25 Nov 2020 12:43:37 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id m13so3459097ioq.9 for ; Wed, 25 Nov 2020 12:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P9Sk11h9gvFAH4TJbsq5a6DSCQ7FEKDBAacFuyysC1U=; b=T5LW9cXDByjogf1ZQDr+Pepr8JKbs1fTTCmcpXPDFVCeQcHf3Qlt3iI9NzcLLkq21R LxyAOOsgp4A/WmhwomYUvKOqMVuvdA10ntbN4wZrKiHG28eZCaaLrVfZAMIsX1MRzihw DjQ/py1EysgrJwRnWco03jxGJsQvmWjJ/jNjbtW6NtbRNG+m5rhR8FFCnTKuOcHHFswX AB3eydx9JJrdtgITlxl1oE2bnW/R2M43lkzcMpdyHobwM6FrB5Fs7r51rm1nRgBZLdX/ RppOveUl9KsqsAkuCkn9r7hQ2wb+s2tF+MftAMzoK48Kr4cXYJmVC43BXTyR8lD+M6eG W9VA== 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=P9Sk11h9gvFAH4TJbsq5a6DSCQ7FEKDBAacFuyysC1U=; b=roETD4axI9e/la+mfNp++H/tvswyk0A3uqAFBWF0O2OAm0ZN4Gcbbvf5RrydLt0L3U EKyNmUf+wsCseHQEc/J/x0/dyQXyosCRkGb1mrbVlmnHinQac8JW35CG+O8tJR+doNFw TmypPf+YuMl04pkwNaPIx61r3G3G5RUOk4SjL0Z/RjqBbI4XNrVRrJmGh01OncnCWDjV r7uH3utiGAyIoiq2UERub6ff/56p2JSNeKZsjMO4ZN2f1xXahfUbG1N6s1GmDI66yGDc TDw0woYIrCr9II0R/vqqILw9jYE+4USXB6uT7aipFdjYXFjuUchhpSUpWhG9DWKbbJSZ FsSQ== X-Gm-Message-State: AOAM533PQNAEQ+XOjJtXSiy1OsCPJ2Q7SKNVCtt3tOVbdf/jBc+NVd9a 6DdC1yw9xEn51Oa7LF4ZDEQlQYEA6u9k6FgzLxg= X-Google-Smtp-Source: ABdhPJzXEt+pLjI28MwFYXJ3DgGskTh7lbpVVMkN79oamaopN8A2XEhtse1L1yCH1X+AboYJFD0CtICCUOLDFuDExfI= X-Received: by 2002:a6b:4401:: with SMTP id r1mr4073807ioa.78.1606337016929; Wed, 25 Nov 2020 12:43:36 -0800 (PST) MIME-Version: 1.0 References: <9D3D60CC-5019-4CC2-BE2D-4EF789FABE31@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 25 Nov 2020 21:43:25 +0100 Message-ID: To: Dick Hardt Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000489f6e05b4f47b69" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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, 25 Nov 2020 20:43:40 -0000 --000000000000489f6e05b4f47b69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Couldn't say I agree here. Will send more info and explanations when I reopen my laptop tomorrow morning :-) Fabien Le mer. 25 nov. 2020 =C3=A0 21:37, Dick Hardt a =C3= =A9crit : > Would you share a link? I see the discussion on the access token pull > request, but no discussion on unique URLs. > > Do you agree with my assessment of the "access token"? > > =E1=90=A7 > > On Wed, Nov 25, 2020 at 12:33 PM Fabien Imbault > wrote: > >> Hi Dick, >> >> There is more context on the rationale, from the comments the editors >> made to the issues yesterday. >> >> Especially the part on unique URLs. >> >> Best >> Fabien >> >> >> Le mer. 25 nov. 2020 =C3=A0 21:27, Dick Hardt a = =C3=A9crit : >> >>> >>> There are numerous issues with the proposal: >>> >>> 1) It is not an "access token". Just because it is sent in the HTTP >>> Authorization header does not make it an access token. The client has >>> already authenticated before the "access token" is presented. The AS >>> already knows what the client is authorized to do at the AS before the >>> "access token" is issued, so it is not needed to represent authorizatio= n as >>> an access token is with an RS. The "access token" is serving the purpos= e >>> that the transaction handle served in the past -- the context of the >>> transaction. Per my earlier comments, this "access token" is more like = a >>> cookie. >>> >>> 2) Calling it an "access token" is changing the well known meaning of a= n >>> access token as used in OAuth. The client authenticates to the AS APIs = in >>> OAuth 2.0, it does not present an access token. Access tokens are prese= nted >>> by a client to an RS to prove authorization. >>> >>> 3) What the client has to do with the "access token" is not the same as >>> access tokens for an RS. The client gets a new "access token" for each >>> grant request, and for each API call to the AS, and the client learns i= t >>> can not make any more API calls for that specific request when it does = not >>> get an "access token" back. This is a completely different design patte= rn >>> than calling an RS API with an access token, and is a new design patter= n >>> for calling APIs. This adds complexity to the client that it would not >>> normally have, and I don't think GNAP is the right place to start a new >>> design pattern. >>> >>> 4) Clients that only want claims from the AS and no access tokens will >>> be required to support an API calling mechanism they would not have to >>> support otherwise. >>> >>> 5) If the AS does not provide an "access token", there is no mechanism >>> for a client to delete the request, as the client is not allowed to mak= e a >>> call without an "access token". >>> >>> 6) There is no standard identifier for the request. Debugging and >>> auditing are hampered by the client and AS having no standard way to >>> identifying a request. While one AS may provide a unique URL for each g= rant >>> request, another AS may use a persistent "access token" to identify the >>> grant request, and other ASs may issue a new "access token" on each API >>> call, providing no persistent identifier for the request. >>> >>> Representing each grant request with an unique URL has the following >>> advantages: >>> >>> 1) It follows the common REST like API model where each resource has a >>> URI which is well understood. >>> >>> 2) There is only one way for a client and AS to identify a grant reques= t. >>> >>> 3) There is a standard, persistent unique identifier for the client and >>> AS to refer to a grant request. >>> >>> >>> FWIW: the statement that it is more "access token" like than a cookie >>> because it is bound to a key is untrue. Binding cookies to keys was the >>> motivation for RFC 8471 - The Token Binding Protocol Version 1.0. Havin= g >>> the "access token" bound to a key provides no value as the AS already k= nows >>> which client it is through client authentication. The only time that wo= uld >>> not be the case is if the "access token" was self contained and the gra= nt >>> request APIs were at an server independent of the AS where the original >>> request was made. >>> >>> >>> >>> >>> =E1=90=A7 >>> >>> On Mon, Nov 23, 2020 at 9:55 AM Justin Richer wrote: >>> >>>> An important distinction here is that the access tokens in question ar= e >>>> always going to be bound to a key for presentation purposes, so in man= y >>>> ways they are quite distinct from cookies. >>>> >>>> Since =E2=80=9Ccontinuation=E2=80=9D in its various forms is now an AP= I, why not treat >>>> it like other APIs the client would call and use access tokens? >>>> >>>> Apart from design choices, what is the negative cost of requiring an >>>> access token? >>>> >>>> We aren=E2=80=99t asking the client to do anything it=E2=80=99s not al= ready doing. Even >>>> if the client is going to use bearer tokens at a downstream RS, the >>>> signature presentation mechanism for the bound access token at the >>>> continuation API is exactly the same as what the client used in the fi= rst >>>> place to get the continuation response. >>>> >>>> We aren=E2=80=99t asking the AS to do anything special either since it= already >>>> needs to be able to validate the signature inbound, and it needs to be= able >>>> to reference an artifact for the ongoing request (stateful or not). >>>> >>>> =E2=80=94 Justin >>>> >>>> On Nov 23, 2020, at 12:44 PM, Fabien Imbault >>>> wrote: >>>> >>>> Yes. "Cookies were designed to be a reliable mechanism for websites to >>>> remember stateful inform= ation". >>>> We're not storing anything, it's just a reference. >>>> >>>> On Mon, Nov 23, 2020 at 6:38 PM Dick Hardt >>>> wrote: >>>> >>>>> To clarify, I am talking about HTTP cookies, which are effectively >>>>> opaque to the web browser, and used by the web server to store state. >>>>> >>>>> https://en.wikipedia.org/wiki/HTTP_cookie >>>>> >>>>> A client may use local storage for saving state, but that is >>>>> completely different from an HTTP cookie which is issued by the serve= r. >>>>> =E1=90=A7 >>>>> >>>>> On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> If the client was directly managing/storing its state, then it would >>>>>> indeed effectively work as a cookie. >>>>>> But here the access token merely provides a map to the current state >>>>>> (opaque to the client), as managed/controlled by the AS. >>>>>> It's a very different use case compared to what cookies are used for >>>>>> in webapps. >>>>>> >>>>>> Having a unique URL is a different design (XAuth was more aligned >>>>>> with that idea). >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt >>>>>> wrote: >>>>>> >>>>>>> If all the access token is doing is expressing "please continue" ..= . >>>>>>> why do we need an access token? >>>>>>> >>>>>>> Why not just have a unique URL for the grant request? The URL is th= e >>>>>>> identifier for the grant request that allows the client to delete, = update, >>>>>>> etc. >>>>>>> >>>>>>> How the access token is being used is just like a cookie. The AS >>>>>>> gives a string to the client and the client must pass the string ba= ck to >>>>>>> the AS when it calls it, the AS may then give a new string to the c= lient >>>>>>> for the next call. Works like a cookie. I don't know why you think = there >>>>>>> are legal issues around this. >>>>>>> >>>>>>> /Dick >>>>>>> >>>>>>> >>>>>>> >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Dick, >>>>>>>> >>>>>>>> In GNAP, the client isn't managing state (unlike a web app), the >>>>>>>> entire point is that the lifecycle should be managed by the AS. >>>>>>>> >>>>>>>> As in any state machine, there are states and transitions. Here >>>>>>>> we're not passing state, merely expressing "please continue". The = client >>>>>>>> can be completely unaware of the underlying state. >>>>>>>> In effect the client only has the ability to ask the server to >>>>>>>> generate the next transition. >>>>>>>> >>>>>>>> So I don't think you can compare that to cookies. It's a different >>>>>>>> behavior. BTW if it was the case it would lead to a whole new clas= s of >>>>>>>> issues, because there's an entire legal framework around cookies..= . >>>>>>>> >>>>>>>> To avoid confusion with a standard access token, we have the "key" >>>>>>>> field. My proposal would be to make it more explicitly (cf comment= in issue >>>>>>>> 67). >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> >>>>>>>> Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt a >>>>>>>> =C3=A9crit : >>>>>>>> >>>>>>>>> When I look at how GNAP is using access tokens for continuation >>>>>>>>> requests, and the pull request #129 >>>>>>>>> >>>>>>>>> >>>>>>>>> Those "access tokens" look a lot more like cookies (managing >>>>>>>>> state) than how access tokens are usually used (representing >>>>>>>>> authorization). See table below. >>>>>>>>> >>>>>>>>> If there is a real requirement for passing state back and forth >>>>>>>>> between a server (the AS in this case) and the client when making= API >>>>>>>>> calls, then I suggest that is out of scope for GNAP as I see it b= eing a >>>>>>>>> general purpose mechanism for any API. >>>>>>>>> >>>>>>>>> /Dick >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *cookies*- issued by server being accessed >>>>>>>>> - are not presented to other servers >>>>>>>>> - issued after first access >>>>>>>>> - may be different for different URLs >>>>>>>>> - may be updated on each access >>>>>>>>> - represents the context of a session (state) >>>>>>>>> >>>>>>>>> >>>>>>>>> *access tokens*- issued by an independent service (AS) >>>>>>>>> - may be used at any URL at the RS >>>>>>>>> - new ones issued by AS as needed >>>>>>>>> - represents authorization granted to a client at an RS >>>>>>>>> =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 >>>> >>>> >>>> --000000000000489f6e05b4f47b69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Couldn't say I agree here.=C2=A0
Will send more info and explanations when I reopen= my laptop tomorrow morning :-)

Fabien=C2=A0

Le mer. 25 nov. 2020 =C3=A0 21:37, Dick Hardt= <dick.hardt@gmail.com> a= =C3=A9crit=C2=A0:
Would you share a link? I see the discussion on the access token pull requ= est, but no discussion on unique URLs.

Do you agree with= my assessment of the "access token"?

<= div hspace=3D"streak-pt-mark" style=3D"max-height:1px">3D""=E1=90=A7

On Wed, Nov 25, 2020 at 12:33 PM Fabien Imbault &l= t;fabien.imbault@gmail.com> wrote:
Hi Dick,

There is more context on the rationale, from = the comments the editors made to the issues yesterday.=C2=A0

Especially the part on unique URLs.= =C2=A0

Best=C2=A0
<= div dir=3D"auto">Fabien=C2=A0


Le mer. 25 nov. 2020 =C3=A0= 21:27, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
=

There are numerous issues with the proposal:
=
1) It is not an "access token". Just because=C2=A0= it is sent in the HTTP Authorization header does not make it an access toke= n. The client has already authenticated before the "access token"= is presented. The AS already knows what the client is authorized to do at = the AS before the "access token" is issued, so it is not=C2=A0nee= ded to represent authorization as an access token is with an RS. The "= access token" is serving the purpose that the transaction handle=C2=A0= served in the past --=C2=A0the context of the transaction. Per my earlier c= omments, this "access token" is more like a cookie.
2) Calling it an "access token" is changing=C2=A0the = well known meaning of an access token as used in OAuth. The client authenti= cates to the AS APIs in OAuth 2.0, it does not present an access token. Acc= ess tokens are presented by a client to an RS to prove authorization.=C2=A0=

3) What the client has to do with the "acces= s token" is not the same as access tokens for an RS. The client gets a= new "access token" for each grant request, and for each API call= to the AS, and the client learns it can not make any more API calls for th= at specific request when it does not get an "access token" back. = This is a completely different design pattern than calling an RS API with a= n access token,=C2=A0and is a new design pattern for calling APIs. This add= s complexity to the client that it would not normally have, and I don't= think GNAP is the right place to start a new design pattern.
4) Clients that only want claims from the AS and no access toke= ns will be required to support an API calling mechanism they would not have= to support otherwise.=C2=A0

5) If the AS does not= provide an "access token", there is no mechanism for a client to= delete the request, as the client is not allowed to make a call without an= "access token".

6) There is no standard= identifier for the request. Debugging and auditing are hampered by the cli= ent and AS having no standard way to identifying a request. While one AS ma= y provide a unique URL for each grant request, another AS may use a persist= ent "access token" to identify the grant request, and other ASs m= ay=C2=A0issue a new "access token" on each API call, providing no= persistent identifier for the request.

Representi= ng each grant request with an unique URL has the following advantages:

1) It follows the common REST like API model where eac= h resource has a URI which is well understood.

2) = There is only one way for a client and AS to identify a grant request.

3) There is a standard, persistent unique identifier f= or the client and AS to refer to a grant request.

=
FWIW: the statement that it is more "access token"= like than a cookie because it is bound to a key is untrue. Binding cookies= to keys was the motivation for RFC 8471 - The Token Binding Protocol Versi= on 1.0. Having the "access token" bound to a key provides no valu= e as the AS already knows which client it is through client authentication.= The only time that would not be the case is if the "access token"= ; was self contained and the grant request APIs were at an server independe= nt=C2=A0of the AS where the original request was made.=C2=A0

=



3D""=E1=90= =A7

On Mon, Nov 23, 2020 at 9:55 AM Justin Richer <jricher= @mit.edu> wrote:
An important distinction here is that the access tokens i= n question are always going to be bound to a key for presentation purposes,= so in many ways they are quite distinct from cookies.

=
Since =E2=80=9Ccontinuation=E2=80=9D in its various forms is now an AP= I, why not treat it like other APIs the client would call and use access to= kens?

Apart from design choices, what is the negat= ive cost of requiring an access token?

We aren=E2= =80=99t asking the client to do anything it=E2=80=99s not already doing. Ev= en if the client is going to use bearer tokens at a downstream RS, the sign= ature presentation mechanism for the bound access token at the continuation= API is exactly the same as what the client used in the first place to get = the continuation response.=C2=A0

We aren=E2=80=99t= asking the AS to do anything special either since it already needs to be a= ble to validate the signature inbound, and it needs to be able to reference= an artifact for the ongoing request (stateful or not).=C2=A0
=C2=A0=E2=80=94 Justin

=
On Nov 23, 2020, at 12:44 PM, Fabien Imbault <fabi= en.imbault@gmail.com> wrote:

Yes. &qu= ot;Cookies were designed to be a reliable mechanism for websites to remember= =C2=A0stateful=C2=A0information". We're not storing anyth= ing, it's just a reference.=C2=A0

On Mon, Nov 23, 2020 at 6:38 PM= Dick Hardt <dick.hardt@gmail.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">
To c= larify, I am talking about HTTP cookies, which are effectively opaque to th= e web browser,=C2=A0and used by the web server to store state.

A client may use local storage for = saving=C2=A0state, but that is completely different from an HTTP cookie whi= ch is issued by the server.
3D""=E1=90=A7

<= div class=3D"gmail_quote">
On Mon, Nov= 23, 2020 at 8:30 AM Fabien Imbault <fabien.imbault@gma= il.com> wrote:
If the client was directly man= aging/storing its state, then it would indeed effectively work as a cookie.= =C2=A0
But here the access token merely provides a map to the= current state (opaque to the client), as managed/controlled by the AS.=C2= =A0
It's a very different use case compared to what cooki= es are used for in webapps.=C2=A0

Having a unique = URL is a different design (XAuth was more aligned with that idea).=C2=A0

Fabien
=C2=A0=C2=A0

On Mon, Nov 23, 2= 020 at 5:09 PM Dick Hardt <dick.hardt@gmail.com> w= rote:
If all the access token is doing is expressing "please contin= ue" ... why do we need an access token?

Why not jus= t have a unique=C2=A0URL for the grant request? The URL is the identifier f= or the grant request that allows the client to delete, update, etc.

How the access token is being used is just like a cookie.= The AS gives a string to the client and the client must pass the string ba= ck to the AS when it calls it,=C2=A0the AS may then give a new string=C2=A0= to the client for the next call. Works like a cookie. I don't know why = you think there are legal issues around this.=C2=A0

/Dick



3D""= =E1=90=A7

On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Dick,

In GNAP, the client isn't managing sta= te (unlike a web app), the entire point is that the lifecycle should be man= aged by the AS.=C2=A0

As= in any state machine, there are states and transitions. Here we're not= passing state, merely expressing "please continue". The client c= an be completely unaware of the underlying state.=C2=A0
In effect the client only has th= e ability to ask the server to generate the next transition.

So I don't think you ca= n compare that to cookies. It's a different behavior. BTW if it was the= case it would lead to a whole new class of issues, because there's an = entire legal framework around cookies...=C2=A0

<= /div>
To avoid confusion with a standard access token, we = have the "key" field. My proposal would be to make it more explic= itly (cf comment in issue 67).

Fabien=C2=A0


Le lun. 23 nov. 2020 =C3=A0 02:06, Dick= Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
<= div>When I look at how GNAP is using access tokens for continuation request= s, and the pull request=C2=A0#= 129

Those "access tokens" look a lot= more like cookies (managing state) than how access tokens are usually used= (representing authorization). See table below.

If= there is a real requirement for passing state back and forth between a ser= ver (the AS in this case) and the client when making API calls, then I sugg= est that is out of scope for GNAP as I see it being a general=C2=A0purpose = mechanism for any API.

/Dick


cookies
- issued by server being accessed
- are not pr= esented to other servers
- issued after first access
- may be differe= nt for different URLs
- may be updated on each access
- represents th= e context of a session (state)

access tokens
- issued by a= n independent service (AS)
- may be used at any URL at the RS
- new o= nes issued by AS as needed
- represents authorization granted to a clien= t at an RS
3D""= =E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
<= /blockquote>

--000000000000489f6e05b4f47b69-- From nobody Wed Nov 25 15:15:23 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 22FA43A0332 for ; Wed, 25 Nov 2020 15:15:22 -0800 (PST) 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 IV2majNS0kez for ; Wed, 25 Nov 2020 15:15:20 -0800 (PST) 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 71C403A0317 for ; Wed, 25 Nov 2020 15:15:19 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id r18so234128ljc.2 for ; Wed, 25 Nov 2020 15:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OBWbJLjXepKtDcp6+TqCifvNny6RWtnuC4968wB1sUo=; b=cHSvaaTIb1R2I782soI1EGtQ3t2FeNoRAgWj5cE0WIzaUsPHivTG5jdqu1fnLzaGw+ Cs54R/u/jlSkrCKJghp3Km8i2SII38HHF5x6h7WTDv8NOAlToFIUAlJwy5sGXp3YBMeE +0AEZtOYRjSv4J/uZSsVcPsEkb6xG7eRk0wFq1ViXmClf8CGr1P8YIWhi9PSP1knGBDX 0k8Wx6djO6CiEfBhX13BrqOriqPXS9rto+al1J5izZiBtZquacbiD3gonHEbQS1W1Ibl BBaTgvr+0Bcnzm33OOamidXC+zqrDjbVRe4EhxZ4m/2Nih72ntp9WnfWDACy4T7IxAce 91Rg== 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=OBWbJLjXepKtDcp6+TqCifvNny6RWtnuC4968wB1sUo=; b=g9DCMgF4JSOLUwxXVBhExa5S9j0hM2A9zWGzTAEs53zMu/bruiSDRaBkMoWD/k5e1R FwN6OIieXibkheTrvdb8OuKaFKvVrRjydVhQVXsWwOqR9hDF1xIdm8EWCXh4nJAC00m9 0/OKlLQwjhFhEyX6Szz8+XMdPqNu30wXSPvKQIdA4I4v79RnAzcnNVzuhEV0F3vu13Q5 E7D+bksjq+Jy3Z2IAFcAd3k232BSy+Sz/H+Yo3AMfuhLxqWI4qEzardiQTxFA+GH27yS tkBMCNvKE9vevRl1e2HFxV5A7r4Xgx8aPGRENHvYfnFf4yZsXSoLCs5/CUGFLMnWsHp2 kacw== X-Gm-Message-State: AOAM5300BeYD5Ry9AQ2O2V9tx9dXAs8GhHf325Wpy31EdBeqJoK+AFqs EWBVWkH1dIGXbe9bn15sqgo5jWWVdmlKIRILc3Y= X-Google-Smtp-Source: ABdhPJy8AvHQyk/4DpuHAZ/J5fBLy5mJWi3tbFifsDt23OqcC+HkKj9ms7FwiOY4OeR65njoOhEoTP8F4BqzJtfglVg= X-Received: by 2002:a2e:a0cf:: with SMTP id f15mr154601ljm.142.1606346117076; Wed, 25 Nov 2020 15:15:17 -0800 (PST) MIME-Version: 1.0 References: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> In-Reply-To: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> From: Dick Hardt Date: Wed, 25 Nov 2020 15:14:40 -0800 Message-ID: To: Yaron Sheffer Cc: Aaron Parecki , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000b1daa005b4f69963" Archived-At: Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues 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, 25 Nov 2020 23:15:22 -0000 --000000000000b1daa005b4f69963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What is the process for terminology? Some terms have issues, others don't. I see a PR for changing RQ to CI -- but it is not clear where the discussion for that, and other terms will be. =E1=90=A7 On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer wrote: > Commenting on the proposed process (chair hat off): > > > > I think =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once som= ething is closed, > we should be reasonably confident that it is resolved for good. People > rarely search through closed issues. > > > > Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. In= stead, I suggest > to mark such issues with future milestones, e.g. =E2=80=9CIETF110=E2=80= =9D, meaning that at > this time we will review the issue. Otherwise, the =E2=80=9Cpostponed=E2= =80=9D issues will > probably suffer the destiny of all =E2=80=9Clow priority=E2=80=9D issues = =E2=80=93 they will be > ignored for months and eventually closed en masse. See [1] for GitHub > milestones. > > > > Otherwise I am fine with the rest of the process. > > > > Thanks, > > Yaron > > > > [1] > https://docs.github.com/en/free-pro-team@latest/github/managing-your-work= -on-github/about-milestones > > > > > > *From: *TXAuth on behalf of Aaron Parecki < > aaron@parecki.com> > *Date: *Wednesday, November 25, 2020 at 18:37 > *To: *GNAP Mailing List > *Subject: *[GNAP] GNAP Editors' Use of GitHub Issues > > > > The editors met yesterday to discuss the issues that were pulled out of > the previous draft text and document a process for how to resolve these a= nd > future issues. We would like to explain how we plan on using labels on > GitHub issues to keep track of discussions and keep things moving. > > When there are substantive issues or pull requests, the editors will avoi= d > merging or closing those outright, and instead mark them as "pending", so > that these can be brought to the attention of the larger group. If no > additional discussion happens on these, the merge or close action will be > taken in 7 days. Note for this first round we are setting the deadline fo= r > the issues below as Dec 11th due to the US holiday and the fact that this > is the first time using this process. > > "Pending Merge" > When specific text is proposed in a PR (by anyone, not limited to the > editors), and the editors believe this text reflects the consensus of the > working group, this marks that the PR will be merged in 7 days unless the= re > is a clear alternative proposal accepted by the working group. > > "Pending Close" > When the editors believe an issue no longer needs discussion, we'll mark > it "Pending Close". The issue will be closed in 7 days unless someone > brings new information to the discussion. This tag is not applied to issu= es > that will be closed by a specific pull request. > > There are two additional labels we will use to flag issues to the group. > > "Needs Text" > The editors suggest this issue needs additional text in the spec to > clarify why this section is needed and under what circumstances. Without = a > concrete proposal of text to be included in the spec, this section will b= e > removed in a future update. > > "Postponed" > This issue can be reconsidered in the future with a more concrete > discussion but is not targeted for immediate concrete changes to the spec > text. When used on its own, this label does not indicate that an issue is > targeted to be closed. An issue may also be marked "Pending Close", and > this is used so that we can distinguish closed issues between discussions > that have concluded or things that we may want to revisit in the future. > Remember that closed issues are not deleted and their contents are still > findable and readable, and that new issues can reference closed issues. > > With these labels in mind, here are the list of issues and their statuses > we were able to discuss on our last editor's call. The action on these > pending issues will be taken on Dec 11th to give the group enough time to > review this list. For this first round, many of the issues are marked > "Pending Close" as we're looking for low hanging fruit to prune the list = of > issues down. In the future, you can expect to see more "Pending Merge" > issues as we're bringing proposed text to review by the WG. > > Postponed: > > * Generic claim extension mechanism > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 > > Pending Merge: > > * Make access token mandatory for continuation API calls > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 > > Postponed and Pending Close: > > * Fetchable Keys > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 > * Including OpenID Connect Claims > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 > * Application communication with back-end > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 > * Additional post-interaction protocols > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 > > Pending Close: > > * HTTP PUT vs POST for rotating access tokens > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 > * Use of hash with unique callback URL > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 > * Interaction considerations > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 > * Expanding dynamic reference handles > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 > * Post interaction callback nonce > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73 > * Unique callback URIs > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 > * Instance identifier > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 > * Requesting resources by reference > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36 > * Mapping resource references > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 > > --- > > Aaron Parecki > > https://aaronparecki.com > > > > -- 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 > --000000000000b1daa005b4f69963 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What is the process for terminology? Some terms have issue= s, others don't.

I see a PR for changing RQ to CI --= but it is not clear where the discussion for that, and other terms will be= .

3D""=E1=90=A7

On Wed, Nov 25, 2020= at 10:27 AM Yaron Sheffer <yar= onf.ietf@gmail.com> wrote:
=

Commenting on the proposed process (chair hat off):

=C2=A0

I think = =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once something is = closed, we should be reasonably confident that it is resolved for good. Peo= ple rarely search through closed issues.

=C2=A0

Moreover, IMO the labe= l =E2=80=9Cpostponed=E2=80=9D is not actionable. Instead, I suggest to mark= such issues with future milestones, e.g. =E2=80=9CIETF110=E2=80=9D, meanin= g that at this time we will review the issue. Otherwise, the =E2=80=9Cpostp= oned=E2=80=9D issues will probably suffer the destiny of all =E2=80=9Clow p= riority=E2=80=9D issues =E2=80=93 they will be ignored for months and event= ually closed en masse. See [1] for GitHub milestones.

=C2=A0

Otherwise= I am fine with the rest of the process.

=C2=A0

Thanks,<= /p>

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

=C2=A0

[1] https://docs.github.com/en= /free-pro-team@latest/github/managing-your-work-on-github/about-milestones<= /a>

=C2=A0

=C2=A0

From: TXAu= th <txauth-= bounces@ietf.org> on behalf of Aaron Parecki <aaron@parecki.com>
Date: <= /b>Wednesday, November 25, 2020 at 18:37
To: GNAP Mailing List &l= t;txauth@ietf.org&= gt;
Subject: [GNAP] GNAP Editors' Use of GitHub Issues=

=C2=A0

The editors= met yesterday to discuss the issues that were pulled out of the previous d= raft text and document a process for how to resolve these and future issues= . We would like to explain how we plan on using labels on GitHub issues to = keep track of discussions and keep things moving.

When there are sub= stantive issues or pull requests, the editors will avoid merging or closing= those outright, and instead mark them as "pending", so that thes= e can be brought to the attention of the larger group. If no additional dis= cussion happens on these, the merge or close action will be taken in 7 days= . Note for this first round we are setting the deadline for the issues belo= w as Dec 11th due to the US holiday and the fact that this is the first tim= e using this process.

"Pending Merge"
When specific tex= t is proposed in a PR (by anyone, not limited to the editors), and the edit= ors believe this text reflects the consensus of the working group, this mar= ks that the PR will be merged in 7 days unless there is a clear alternative= proposal accepted by the working group.

"Pending Close"When the editors believe an issue no longer needs discussion, we'll m= ark it "Pending Close". The issue will be closed in 7 days unless= someone brings new information to the discussion. This tag is not applied = to issues that will be closed by a specific pull request.

There are = two additional labels we will use to flag issues to the group.

"= ;Needs Text"
The editors suggest this issue needs additional text i= n the spec to clarify why this section is needed and under what circumstanc= es. Without a concrete proposal of text to be included in the spec, this se= ction will be removed in a future update.

"Postponed"
T= his issue can be reconsidered in the future with a more concrete discussion= but is not targeted for immediate concrete changes to the spec text. When = used on its own, this label does not indicate that an issue is targeted to = be closed. An issue may also be marked "Pending Close", and this = is used so that we can distinguish closed issues between discussions that h= ave concluded or things that we may want to revisit in the future. Remember= that closed issues are not deleted and their contents are still findable a= nd readable, and that new issues can reference closed issues.

With t= hese labels in mind, here are the list of issues and their statuses we were= able to discuss on our last editor's call. The action on these pending= issues will be taken on Dec 11th to give the group enough time to review t= his list. For this first round, many of the issues are marked "Pending= Close" as we're looking for low hanging fruit to prune the list o= f issues down. In the future, you can expect to see more "Pending Merg= e" issues as we're bringing proposed text to review by the WG.
=
Postponed:

* Generic claim extension mechanism
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131
=
Pending Merge:

* Make access token mandatory for continuation AP= I calls
** https://github.com/ietf-wg-gnap/gnap-core-prot= ocol/pull/129

Postponed and Pending Close:

* Fetchable Ke= ys
** https://github.com/ietf-wg-gnap/gnap-core-protocol= /issues/47
* Including OpenID Connect Claims
** h= ttps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64
* Applic= ation communication with back-end
** https://github.com/= ietf-wg-gnap/gnap-core-protocol/issues/82
* Additional post-interact= ion protocols
** https://github.com/ietf-wg-gnap/gnap-co= re-protocol/issues/83

Pending Close:
=C2=A0 =C2=A0
* HTTP= PUT vs POST for rotating access tokens
** https://gith= ub.com/ietf-wg-gnap/gnap-core-protocol/issues/100
* Use of hash with= unique callback URL
** https://github.com/ietf-wg-gnap/= gnap-core-protocol/issues/84
* Interaction considerations
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81
* Expanding dynamic reference handles
** https://gi= thub.com/ietf-wg-gnap/gnap-core-protocol/issues/76
* Post interactio= n callback nonce
** https://github.com/ietf-wg-gnap/gnap= -core-protocol/issues/73
* Unique callback URIs
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55
* In= stance identifier
** https://github.com/ietf-wg-gnap/gna= p-core-protocol/issues/46
* Requesting resources by reference
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/3= 6
* Mapping resource references
** https://github= .com/ietf-wg-gnap/gnap-core-protocol/issues/35

-- 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
--000000000000b1daa005b4f69963-- From nobody Wed Nov 25 16:26: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 262B03A0DCF for ; Wed, 25 Nov 2020 16:26:52 -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 56H_M1eVDrbg for ; Wed, 25 Nov 2020 16:26:50 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0: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 026FE3A0B37 for ; Wed, 25 Nov 2020 16:26:49 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id a130so355695oif.7 for ; Wed, 25 Nov 2020 16:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qowjnALXn47XqCllqTJrftZEGZfWKbrsUrZGFsMqVMo=; b=FlnWM5XVpDskwso6FbDefNFD0UwoZr+oSjP51sK7pedJw4tv07fpIK11KTWWptW9Ly XUsBo+3fuCYVwjiW8IaidIczmBoQr0anEy8jmvDZpkpmMSgLp1K8LzcfCHGnW5eoPtMr RQ+GOWVHitImrsTsl9I88qx6fi1vlxIeRS3JfniYnenBLN1AtH0pNTgQY960Q6E61MKW kZiBOQae7mY7U0y2395E4mVffyAYjvJ3xStxVkp3nPuyOOcjZ8+KuhS3PruuWlkGG8Rz XmTxy0y3rUl0mfDjNr9kK1cxD/HG7ZXhTWDhDaVGGOtVcg98tzDs6DzNRt61aVxniDpA vd5A== 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=qowjnALXn47XqCllqTJrftZEGZfWKbrsUrZGFsMqVMo=; b=d5ZeAckJM/ADlj2QLqxvi6vMYlLHjl99rSE3voqi+EeQqZIYHdClZFLPprdA47cKPZ VXnSE9LscJnz9GvyNyNz3aRm10S8KF5DcMHnkVZ+4+CAHYp5LNIL2lk3BuudLL8M8E3Q yR6chxfWLGe8HxgMosfHKz24lU+P/7pT+Nm1MdljHdiDF0DMHU3AXInvADSocaxiCKXT /J8i3uxsFKXCpUnTv0ldy1rQaiYC0B6divlkvL/MxcwBuuWLa59zNzdQ8qAhHA2ohlqX 1B2kJ9ao1e+pQ0Ru91wIKCBh/Jt3wQUxpXH7p50syZ8ERsl6qvGRbp+4q2gNlbqNuKfy rs6g== X-Gm-Message-State: AOAM533tENmwt8ZXxnlJDxyu8SDwVdgcEDLxBU5ua4qLv1nsFOF+PHMB 8YIfaN9I4BNeY4sKkr1sxjbCDdaoJVFM9pH0o63KW1kXJK4= X-Google-Smtp-Source: ABdhPJzwHO+znvez2NzmSMyBuQfs6RoNhpB2yGiSwOEEjDHLtrCv5WBqDmHpghjJ+kvEHYmh66NLqfgFo8quOrIB3ls= X-Received: by 2002:aca:5291:: with SMTP id g139mr458666oib.63.1606350409253; Wed, 25 Nov 2020 16:26:49 -0800 (PST) MIME-Version: 1.0 References: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> In-Reply-To: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> From: Tom Jones Date: Wed, 25 Nov 2020 16:26:38 -0800 Message-ID: To: Yaron Sheffer Cc: Aaron Parecki , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000087450e05b4f799e9" Archived-At: Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues 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, 26 Nov 2020 00:26:52 -0000 --00000000000087450e05b4f799e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i agree - drop postponed - if you can't say till when, then close. Issues can always be added by anyone at anytime. Peace ..tom On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer wrote: > Commenting on the proposed process (chair hat off): > > > > I think =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once som= ething is closed, > we should be reasonably confident that it is resolved for good. People > rarely search through closed issues. > > > > Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. In= stead, I suggest > to mark such issues with future milestones, e.g. =E2=80=9CIETF110=E2=80= =9D, meaning that at > this time we will review the issue. Otherwise, the =E2=80=9Cpostponed=E2= =80=9D issues will > probably suffer the destiny of all =E2=80=9Clow priority=E2=80=9D issues = =E2=80=93 they will be > ignored for months and eventually closed en masse. See [1] for GitHub > milestones. > > > > Otherwise I am fine with the rest of the process. > > > > Thanks, > > Yaron > > > > [1] > https://docs.github.com/en/free-pro-team@latest/github/managing-your-work= -on-github/about-milestones > > > > > > *From: *TXAuth on behalf of Aaron Parecki < > aaron@parecki.com> > *Date: *Wednesday, November 25, 2020 at 18:37 > *To: *GNAP Mailing List > *Subject: *[GNAP] GNAP Editors' Use of GitHub Issues > > > > The editors met yesterday to discuss the issues that were pulled out of > the previous draft text and document a process for how to resolve these a= nd > future issues. We would like to explain how we plan on using labels on > GitHub issues to keep track of discussions and keep things moving. > > When there are substantive issues or pull requests, the editors will avoi= d > merging or closing those outright, and instead mark them as "pending", so > that these can be brought to the attention of the larger group. If no > additional discussion happens on these, the merge or close action will be > taken in 7 days. Note for this first round we are setting the deadline fo= r > the issues below as Dec 11th due to the US holiday and the fact that this > is the first time using this process. > > "Pending Merge" > When specific text is proposed in a PR (by anyone, not limited to the > editors), and the editors believe this text reflects the consensus of the > working group, this marks that the PR will be merged in 7 days unless the= re > is a clear alternative proposal accepted by the working group. > > "Pending Close" > When the editors believe an issue no longer needs discussion, we'll mark > it "Pending Close". The issue will be closed in 7 days unless someone > brings new information to the discussion. This tag is not applied to issu= es > that will be closed by a specific pull request. > > There are two additional labels we will use to flag issues to the group. > > "Needs Text" > The editors suggest this issue needs additional text in the spec to > clarify why this section is needed and under what circumstances. Without = a > concrete proposal of text to be included in the spec, this section will b= e > removed in a future update. > > "Postponed" > This issue can be reconsidered in the future with a more concrete > discussion but is not targeted for immediate concrete changes to the spec > text. When used on its own, this label does not indicate that an issue is > targeted to be closed. An issue may also be marked "Pending Close", and > this is used so that we can distinguish closed issues between discussions > that have concluded or things that we may want to revisit in the future. > Remember that closed issues are not deleted and their contents are still > findable and readable, and that new issues can reference closed issues. > > With these labels in mind, here are the list of issues and their statuses > we were able to discuss on our last editor's call. The action on these > pending issues will be taken on Dec 11th to give the group enough time to > review this list. For this first round, many of the issues are marked > "Pending Close" as we're looking for low hanging fruit to prune the list = of > issues down. In the future, you can expect to see more "Pending Merge" > issues as we're bringing proposed text to review by the WG. > > Postponed: > > * Generic claim extension mechanism > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 > > Pending Merge: > > * Make access token mandatory for continuation API calls > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 > > Postponed and Pending Close: > > * Fetchable Keys > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 > * Including OpenID Connect Claims > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 > * Application communication with back-end > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 > * Additional post-interaction protocols > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 > > Pending Close: > > * HTTP PUT vs POST for rotating access tokens > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 > * Use of hash with unique callback URL > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 > * Interaction considerations > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 > * Expanding dynamic reference handles > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 > * Post interaction callback nonce > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73 > * Unique callback URIs > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 > * Instance identifier > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 > * Requesting resources by reference > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36 > * Mapping resource references > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 > > --- > > Aaron Parecki > > https://aaronparecki.com > > > > -- 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 > --00000000000087450e05b4f799e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i agree - drop postponed=C2=A0- if you can't say till = when, then close. Issues can always be added by anyone at anytime.
Peace ..tom
<= br>

On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Commenting on the proposed process (chair hat of= f):

=C2=A0

I think =E2=80=9Cpostponed=E2=80=9D issues should not be cl= osed. Once something is closed, we should be reasonably confident that it i= s resolved for good. People rarely search through closed issues.<= /u>

=C2=A0

Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. In= stead, I suggest to mark such issues with future milestones, e.g. =E2=80=9C= IETF110=E2=80=9D, meaning that at this time we will review the issue. Other= wise, the =E2=80=9Cpostponed=E2=80=9D issues will probably suffer the desti= ny of all =E2=80=9Clow priority=E2=80=9D issues =E2=80=93 they will be igno= red for months and eventually closed en masse. See [1] for GitHub milestone= s.

=C2=A0

Otherwise I am fine with the rest of the process.<= /u>

=C2=A0

Thanks,

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

=C2=A0

[1] https= ://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-git= hub/about-milestones

=C2= =A0

=C2=A0

From: TXAuth <txauth-bounces@ietf.org> on behalf of Aaron Parecki &l= t;aaron@parecki.com<= /a>>
Date: Wednesday, November 25, 2020 at 18:37
To: GNAP Mailing List <txauth@ietf.org>
Subject: [GNAP] GNAP Editors' Use of= GitHub Issues

=C2=A0

The editors met yesterday to discuss the issues that were pulled = out of the previous draft text and document a process for how to resolve th= ese and future issues. We would like to explain how we plan on using labels= on GitHub issues to keep track of discussions and keep things moving.
<= br>When there are substantive issues or pull requests, the editors will avo= id merging or closing those outright, and instead mark them as "pendin= g", so that these can be brought to the attention of the larger group.= If no additional discussion happens on these, the merge or close action wi= ll be taken in 7 days. Note for this first round we are setting the deadlin= e for the issues below as Dec 11th due to the US holiday and the fact that = this is the first time using this process.

"Pending Merge"=
When specific text is proposed in a PR (by anyone, not limited to the e= ditors), and the editors believe this text reflects the consensus of the wo= rking group, this marks that the PR will be merged in 7 days unless there i= s a clear alternative proposal accepted by the working group.

"= Pending Close"
When the editors believe an issue no longer needs di= scussion, we'll mark it "Pending Close". The issue will be cl= osed in 7 days unless someone brings new information to the discussion. Thi= s tag is not applied to issues that will be closed by a specific pull reque= st.

There are two additional labels we will use to flag issues to th= e group.

"Needs Text"
The editors suggest this issue ne= eds additional text in the spec to clarify why this section is needed and u= nder what circumstances. Without a concrete proposal of text to be included= in the spec, this section will be removed in a future update.

"= ;Postponed"
This issue can be reconsidered in the future with a mor= e concrete discussion but is not targeted for immediate concrete changes to= the spec text. When used on its own, this label does not indicate that an = issue is targeted to be closed. An issue may also be marked "Pending C= lose", and this is used so that we can distinguish closed issues betwe= en discussions that have concluded or things that we may want to revisit in= the future. Remember that closed issues are not deleted and their contents= are still findable and readable, and that new issues can reference closed = issues.

With these labels in mind, here are the list of issues and t= heir statuses we were able to discuss on our last editor's call. The ac= tion on these pending issues will be taken on Dec 11th to give the group en= ough time to review this list. For this first round, many of the issues are= marked "Pending Close" as we're looking for low hanging frui= t to prune the list of issues down. In the future, you can expect to see mo= re "Pending Merge" issues as we're bringing proposed text to = review by the WG.

Postponed:

* Generic claim extension mechan= ism
** https://github.com/ietf-wg-gnap/gnap-core-protoc= ol/issues/131

Pending Merge:

* Make access token mandator= y for continuation API calls
** https://github.com/ietf-w= g-gnap/gnap-core-protocol/pull/129

Postponed and Pending Close:<= br>
* Fetchable Keys
** https://github.com/ietf-wg-gn= ap/gnap-core-protocol/issues/47
* Including OpenID Connect Claims** https://github.com/ietf-wg-gnap/gnap-core-protocol/issu= es/64
* Application communication with back-end
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82
* Add= itional post-interaction protocols
** https://github.com= /ietf-wg-gnap/gnap-core-protocol/issues/83

Pending Close:
=C2= =A0 =C2=A0
* HTTP PUT vs POST for rotating access tokens
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100
* Use of hash with unique callback URL
** https://= github.com/ietf-wg-gnap/gnap-core-protocol/issues/84
* Interaction c= onsiderations
** https://github.com/ietf-wg-gnap/gnap-co= re-protocol/issues/81
* Expanding dynamic reference handles
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76<= /a>
* Post interaction callback nonce
** https://gith= ub.com/ietf-wg-gnap/gnap-core-protocol/issues/73
* Unique callback U= RIs
** https://github.com/ietf-wg-gnap/gnap-core-protoc= ol/issues/55
* Instance identifier
** https://git= hub.com/ietf-wg-gnap/gnap-core-protocol/issues/46
* Requesting resou= rces by reference
** https://github.com/ietf-wg-gnap/gna= p-core-protocol/issues/36
* Mapping resource references
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35

-- 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
--00000000000087450e05b4f799e9-- From nobody Thu Nov 26 01:30:34 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 1D55A3A0B5A for ; Thu, 26 Nov 2020 01:30:32 -0800 (PST) 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_KAM_HTML_FONT_INVALID=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 kzgn57iaP8KO for ; Thu, 26 Nov 2020 01:30:29 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 EA8B93A0B58 for ; Thu, 26 Nov 2020 01:30:28 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id g1so1209852ilk.7 for ; Thu, 26 Nov 2020 01:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=exN79DUN1sepK2uESExwpLI+wm6iJnWWNECE7gS9ges=; b=ivpYQokOlZFAHf28OAtUVncvOztmJJ8Hjr/RVV5wVZG49ZOggNtgpCeaXb+F5N4u/l 0CEUUyxRZduPsJGVRgKtdaSveqoeV9fHgISXeG8aJw5sBVq64kA0AZaSf3k4dzjuEj6B Od4AfQL+QWYHbiewsb/WzXGwgKvx+k/tlZirgff8CVlgsO2GfuKUSOb6JlQye+cNUo1L r2VhdEyq2J49LHa5Sg3O/eClXSLTlpMYpDGAJrDfc+9ocn0hxSyrLx6bggppE4iwZzSn THqUeHnR1aU/4O+LCrKryN0iKybNQmLSfxoAHsqbN5qNCkarBGXBmW6ivFG8dPD9JEV1 LnNA== 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=exN79DUN1sepK2uESExwpLI+wm6iJnWWNECE7gS9ges=; b=YQP0DNIcuTAiiLbSgA5KZB3UtyXd5NQXkr5PU4TBSRu8dX4WWj4SiYZ/o8vPe3YnFF aSyQGc+BTRYdW15glTZqAZYBh1c5Q/nM87ZUEJRjxq22Ks9C3KqaW28fg9fd2hi3ZdKh yBnEv4kSDIxLVTAun8grs4ErId6MskBS4MkKmBFA5ev38NdWWj1xrXJXG+lbRy9NPqo8 fUNxzAUimiP+Yonjaczd63IEArnQ3vAx2M3PtkyAyrsEzk60/tAwaUZXgRp+3/78K25S +ySpkjbKcWU/67YezzxcVEvmyD8nHlZN1zXtFQKjwZ9ofsassRKa7flUC6RFKF9Wv2KK 8ljQ== X-Gm-Message-State: AOAM530gLNGWdNR+ByqpwEoldUhJNSa1+4WNeOezks8IXhRc6UXg5IEW t8KBrJrg6Ces9w0V1YJRL3QCAXHmwtWq9g3edpU= X-Google-Smtp-Source: ABdhPJy7sJ0V8hCicin2oFSn+OftMA1SQBxCpOWTu45V3I1f27cAvCwzIrJxKH/ZwFven9T39qHbAfML/Ov0JVeCJhE= X-Received: by 2002:a92:d80e:: with SMTP id y14mr1762636ilm.68.1606383028143; Thu, 26 Nov 2020 01:30:28 -0800 (PST) MIME-Version: 1.0 References: <9D3D60CC-5019-4CC2-BE2D-4EF789FABE31@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 26 Nov 2020 10:30:17 +0100 Message-ID: To: Dick Hardt Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000c40ce605b4ff31ba" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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, 26 Nov 2020 09:30:32 -0000 --000000000000c40ce605b4ff31ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, We have had several discussions that are related to your items, especially related to unique URLs: * Use of hash with unique callback URL ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 * Unique callback URIs ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 We tried to describe the rationale for the suggested choice as best we could. Please comment on the issues if needed. As for issue 67 / PR 129, the general idea is to make use of access tokens (here also we explained why, but feel free to comment the PR, ideally I'd like to review it after yours, so that I can take it into account). * Refactor key presentation ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/130 Fabien On Wed, Nov 25, 2020 at 9:43 PM Fabien Imbault wrote: > Couldn't say I agree here. > > Will send more info and explanations when I reopen my laptop tomorrow > morning :-) > > Fabien > > Le mer. 25 nov. 2020 =C3=A0 21:37, Dick Hardt a = =C3=A9crit : > >> Would you share a link? I see the discussion on the access token pull >> request, but no discussion on unique URLs. >> >> Do you agree with my assessment of the "access token"? >> >> =E1=90=A7 >> >> On Wed, Nov 25, 2020 at 12:33 PM Fabien Imbault >> wrote: >> >>> Hi Dick, >>> >>> There is more context on the rationale, from the comments the editors >>> made to the issues yesterday. >>> >>> Especially the part on unique URLs. >>> >>> Best >>> Fabien >>> >>> >>> Le mer. 25 nov. 2020 =C3=A0 21:27, Dick Hardt a >>> =C3=A9crit : >>> >>>> >>>> There are numerous issues with the proposal: >>>> >>>> 1) It is not an "access token". Just because it is sent in the HTTP >>>> Authorization header does not make it an access token. The client has >>>> already authenticated before the "access token" is presented. The AS >>>> already knows what the client is authorized to do at the AS before the >>>> "access token" is issued, so it is not needed to represent authorizati= on as >>>> an access token is with an RS. The "access token" is serving the purpo= se >>>> that the transaction handle served in the past -- the context of the >>>> transaction. Per my earlier comments, this "access token" is more like= a >>>> cookie. >>>> >>>> 2) Calling it an "access token" is changing the well known meaning of >>>> an access token as used in OAuth. The client authenticates to the AS A= PIs >>>> in OAuth 2.0, it does not present an access token. Access tokens are >>>> presented by a client to an RS to prove authorization. >>>> >>>> 3) What the client has to do with the "access token" is not the same a= s >>>> access tokens for an RS. The client gets a new "access token" for each >>>> grant request, and for each API call to the AS, and the client learns = it >>>> can not make any more API calls for that specific request when it does= not >>>> get an "access token" back. This is a completely different design patt= ern >>>> than calling an RS API with an access token, and is a new design patte= rn >>>> for calling APIs. This adds complexity to the client that it would not >>>> normally have, and I don't think GNAP is the right place to start a ne= w >>>> design pattern. >>>> >>>> 4) Clients that only want claims from the AS and no access tokens will >>>> be required to support an API calling mechanism they would not have to >>>> support otherwise. >>>> >>>> 5) If the AS does not provide an "access token", there is no mechanism >>>> for a client to delete the request, as the client is not allowed to ma= ke a >>>> call without an "access token". >>>> >>>> 6) There is no standard identifier for the request. Debugging and >>>> auditing are hampered by the client and AS having no standard way to >>>> identifying a request. While one AS may provide a unique URL for each = grant >>>> request, another AS may use a persistent "access token" to identify th= e >>>> grant request, and other ASs may issue a new "access token" on each AP= I >>>> call, providing no persistent identifier for the request. >>>> >>>> Representing each grant request with an unique URL has the following >>>> advantages: >>>> >>>> 1) It follows the common REST like API model where each resource has a >>>> URI which is well understood. >>>> >>>> 2) There is only one way for a client and AS to identify a grant >>>> request. >>>> >>>> 3) There is a standard, persistent unique identifier for the client an= d >>>> AS to refer to a grant request. >>>> >>>> >>>> FWIW: the statement that it is more "access token" like than a cookie >>>> because it is bound to a key is untrue. Binding cookies to keys was th= e >>>> motivation for RFC 8471 - The Token Binding Protocol Version 1.0. Havi= ng >>>> the "access token" bound to a key provides no value as the AS already = knows >>>> which client it is through client authentication. The only time that w= ould >>>> not be the case is if the "access token" was self contained and the gr= ant >>>> request APIs were at an server independent of the AS where the origina= l >>>> request was made. >>>> >>>> >>>> >>>> >>>> =E1=90=A7 >>>> >>>> On Mon, Nov 23, 2020 at 9:55 AM Justin Richer wrote: >>>> >>>>> An important distinction here is that the access tokens in question >>>>> are always going to be bound to a key for presentation purposes, so i= n many >>>>> ways they are quite distinct from cookies. >>>>> >>>>> Since =E2=80=9Ccontinuation=E2=80=9D in its various forms is now an A= PI, why not treat >>>>> it like other APIs the client would call and use access tokens? >>>>> >>>>> Apart from design choices, what is the negative cost of requiring an >>>>> access token? >>>>> >>>>> We aren=E2=80=99t asking the client to do anything it=E2=80=99s not a= lready doing. >>>>> Even if the client is going to use bearer tokens at a downstream RS, = the >>>>> signature presentation mechanism for the bound access token at the >>>>> continuation API is exactly the same as what the client used in the f= irst >>>>> place to get the continuation response. >>>>> >>>>> We aren=E2=80=99t asking the AS to do anything special either since i= t already >>>>> needs to be able to validate the signature inbound, and it needs to b= e able >>>>> to reference an artifact for the ongoing request (stateful or not). >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Nov 23, 2020, at 12:44 PM, Fabien Imbault >>>>> wrote: >>>>> >>>>> Yes. "Cookies were designed to be a reliable mechanism for websites >>>>> to remember stateful in= formation". >>>>> We're not storing anything, it's just a reference. >>>>> >>>>> On Mon, Nov 23, 2020 at 6:38 PM Dick Hardt >>>>> wrote: >>>>> >>>>>> To clarify, I am talking about HTTP cookies, which are effectively >>>>>> opaque to the web browser, and used by the web server to store state= . >>>>>> >>>>>> https://en.wikipedia.org/wiki/HTTP_cookie >>>>>> >>>>>> A client may use local storage for saving state, but that is >>>>>> completely different from an HTTP cookie which is issued by the serv= er. >>>>>> =E1=90=A7 >>>>>> >>>>>> On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> If the client was directly managing/storing its state, then it woul= d >>>>>>> indeed effectively work as a cookie. >>>>>>> But here the access token merely provides a map to the current stat= e >>>>>>> (opaque to the client), as managed/controlled by the AS. >>>>>>> It's a very different use case compared to what cookies are used fo= r >>>>>>> in webapps. >>>>>>> >>>>>>> Having a unique URL is a different design (XAuth was more aligned >>>>>>> with that idea). >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt >>>>>>> wrote: >>>>>>> >>>>>>>> If all the access token is doing is expressing "please continue" >>>>>>>> ... why do we need an access token? >>>>>>>> >>>>>>>> Why not just have a unique URL for the grant request? The URL is >>>>>>>> the identifier for the grant request that allows the client to del= ete, >>>>>>>> update, etc. >>>>>>>> >>>>>>>> How the access token is being used is just like a cookie. The AS >>>>>>>> gives a string to the client and the client must pass the string b= ack to >>>>>>>> the AS when it calls it, the AS may then give a new string to the = client >>>>>>>> for the next call. Works like a cookie. I don't know why you think= there >>>>>>>> are legal issues around this. >>>>>>>> >>>>>>>> /Dick >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> =E1=90=A7 >>>>>>>> >>>>>>>> On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Dick, >>>>>>>>> >>>>>>>>> In GNAP, the client isn't managing state (unlike a web app), the >>>>>>>>> entire point is that the lifecycle should be managed by the AS. >>>>>>>>> >>>>>>>>> As in any state machine, there are states and transitions. Here >>>>>>>>> we're not passing state, merely expressing "please continue". The= client >>>>>>>>> can be completely unaware of the underlying state. >>>>>>>>> In effect the client only has the ability to ask the server to >>>>>>>>> generate the next transition. >>>>>>>>> >>>>>>>>> So I don't think you can compare that to cookies. It's a differen= t >>>>>>>>> behavior. BTW if it was the case it would lead to a whole new cla= ss of >>>>>>>>> issues, because there's an entire legal framework around cookies.= .. >>>>>>>>> >>>>>>>>> To avoid confusion with a standard access token, we have the "key= " >>>>>>>>> field. My proposal would be to make it more explicitly (cf commen= t in issue >>>>>>>>> 67). >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> >>>>>>>>> Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt a >>>>>>>>> =C3=A9crit : >>>>>>>>> >>>>>>>>>> When I look at how GNAP is using access tokens for continuation >>>>>>>>>> requests, and the pull request #129 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Those "access tokens" look a lot more like cookies (managing >>>>>>>>>> state) than how access tokens are usually used (representing >>>>>>>>>> authorization). See table below. >>>>>>>>>> >>>>>>>>>> If there is a real requirement for passing state back and forth >>>>>>>>>> between a server (the AS in this case) and the client when makin= g API >>>>>>>>>> calls, then I suggest that is out of scope for GNAP as I see it = being a >>>>>>>>>> general purpose mechanism for any API. >>>>>>>>>> >>>>>>>>>> /Dick >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *cookies*- issued by server being accessed >>>>>>>>>> - are not presented to other servers >>>>>>>>>> - issued after first access >>>>>>>>>> - may be different for different URLs >>>>>>>>>> - may be updated on each access >>>>>>>>>> - represents the context of a session (state) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *access tokens*- issued by an independent service (AS) >>>>>>>>>> - may be used at any URL at the RS >>>>>>>>>> - new ones issued by AS as needed >>>>>>>>>> - represents authorization granted to a client at an RS >>>>>>>>>> =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 >>>>> >>>>> >>>>> --000000000000c40ce605b4ff31ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,=C2=A0

We have had several dis= cussions that are related to your items, especially related to unique URLs:= =C2=A0

* Use of hash with unique callbac=
k URL
** https://github.com/ietf=
-wg-gnap/gnap-core-protocol/issues/84
* Unique callback URIs
** https://github.com/ietf=
-wg-gnap/gnap-core-protocol/issues/55
We tried to describe the rationale for the suggested cho=
ice as best we could. Please comment on the issues if needed. 
As for issue 67 / PR 129, the gener=
al idea is to make use of access tokens (here also we explained why, but fe=
el free to comment the PR, ideally I'd like to review it after yours, s=
o that I can take it into account).  
* Refactor key presentation
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/130 
<=
pre class=3D"gmail-wordwrap" style=3D"box-sizing:border-box;font-family:SFM=
ono-Regular,Menlo,Monaco,Consolas,"Liberation Mono","Courier=
 New",monospace;margin-top:0px;margin-bottom:1rem;overflow:auto;white-=
space:pre-wrap;word-break:normal;padding:0px">Fabien

On We= d, Nov 25, 2020 at 9:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Couldn't say I= agree here.=C2=A0

Will send m= ore info and explanations when I reopen my laptop tomorrow morning :-)

Fabien=C2=A0

=
Le mer. 25= nov. 2020 =C3=A0 21:37, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
=
Wo= uld you share a link? I see the discussion on the access token pull request= , but no discussion on unique URLs.

Do you agree with my= assessment of the "access token"?

3D""=E1=90=A7

On Wed, Nov 25, 2020 at 12:33 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
Hi Dick,

There is more context on the rationale, fr= om the comments the editors made to the issues yesterday.=C2=A0

Especially the part on unique URLs.= =C2=A0

Best=C2=A0
<= div dir=3D"auto">Fabien=C2=A0


Le mer. 25 nov. 2020 =C3=A0= 21:27, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
=

There are numerous issues with the proposal:
=
1) It is not an "access token". Just because=C2=A0= it is sent in the HTTP Authorization header does not make it an access toke= n. The client has already authenticated before the "access token"= is presented. The AS already knows what the client is authorized to do at = the AS before the "access token" is issued, so it is not=C2=A0nee= ded to represent authorization as an access token is with an RS. The "= access token" is serving the purpose that the transaction handle=C2=A0= served in the past --=C2=A0the context of the transaction. Per my earlier c= omments, this "access token" is more like a cookie.
2) Calling it an "access token" is changing=C2=A0the = well known meaning of an access token as used in OAuth. The client authenti= cates to the AS APIs in OAuth 2.0, it does not present an access token. Acc= ess tokens are presented by a client to an RS to prove authorization.=C2=A0=

3) What the client has to do with the "acces= s token" is not the same as access tokens for an RS. The client gets a= new "access token" for each grant request, and for each API call= to the AS, and the client learns it can not make any more API calls for th= at specific request when it does not get an "access token" back. = This is a completely different design pattern than calling an RS API with a= n access token,=C2=A0and is a new design pattern for calling APIs. This add= s complexity to the client that it would not normally have, and I don't= think GNAP is the right place to start a new design pattern.
4) Clients that only want claims from the AS and no access toke= ns will be required to support an API calling mechanism they would not have= to support otherwise.=C2=A0

5) If the AS does not= provide an "access token", there is no mechanism for a client to= delete the request, as the client is not allowed to make a call without an= "access token".

6) There is no standard= identifier for the request. Debugging and auditing are hampered by the cli= ent and AS having no standard way to identifying a request. While one AS ma= y provide a unique URL for each grant request, another AS may use a persist= ent "access token" to identify the grant request, and other ASs m= ay=C2=A0issue a new "access token" on each API call, providing no= persistent identifier for the request.

Representi= ng each grant request with an unique URL has the following advantages:

1) It follows the common REST like API model where eac= h resource has a URI which is well understood.

2) = There is only one way for a client and AS to identify a grant request.

3) There is a standard, persistent unique identifier f= or the client and AS to refer to a grant request.

=
FWIW: the statement that it is more "access token"= like than a cookie because it is bound to a key is untrue. Binding cookies= to keys was the motivation for RFC 8471 - The Token Binding Protocol Versi= on 1.0. Having the "access token" bound to a key provides no valu= e as the AS already knows which client it is through client authentication.= The only time that would not be the case is if the "access token"= ; was self contained and the grant request APIs were at an server independe= nt=C2=A0of the AS where the original request was made.=C2=A0

=



3D""=E1= =90=A7

On Mon, Nov 23, 2020 at 9:55 AM Justin Richer <jric= her@mit.edu> wrote:
An important distinction here is that the access token= s in question are always going to be bound to a key for presentation purpos= es, so in many ways they are quite distinct from cookies.

Since =E2=80=9Ccontinuation=E2=80=9D in its various forms is now an= API, why not treat it like other APIs the client would call and use access= tokens?

Apart from design choices, what is the ne= gative cost of requiring an access token?

We aren= =E2=80=99t asking the client to do anything it=E2=80=99s not already doing.= Even if the client is going to use bearer tokens at a downstream RS, the s= ignature presentation mechanism for the bound access token at the continuat= ion API is exactly the same as what the client used in the first place to g= et the continuation response.=C2=A0

We aren=E2=80= =99t asking the AS to do anything special either since it already needs to = be able to validate the signature inbound, and it needs to be able to refer= ence an artifact for the ongoing request (stateful or not).=C2=A0

=C2=A0=E2=80=94 Justin

On Nov 23, 2020, at 12:44 PM, Fabien Imbault <= fabien.imbault@gmail.com> wrote:

Yes.= "Cookies were designed to be a reliable mechanism for websites to reme= mber=C2=A0stateful=C2=A0information". We're not storing any= thing, it's just a reference.=C2=A0

On Mon, Nov 23, 2020 at 6:38 = PM Dick Hardt <dick.hardt@gmail.com> wrote:
To= clarify, I am talking about HTTP cookies, which are effectively opaque to = the web browser,=C2=A0and used by the web server to store state.
=

A client may use local storage fo= r saving=C2=A0state, but that is completely different from an HTTP cookie w= hich is issued by the server.
3D""=E1=90=A7
On = Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault <fabien.imb= ault@gmail.com> wrote:
If the client was dire= ctly managing/storing its state, then it would indeed effectively work as a= cookie.=C2=A0
But here the access token merely provides a ma= p to the current state (opaque to the client), as managed/controlled by the= AS.=C2=A0
It's a very different use case compared to wha= t cookies are used for in webapps.=C2=A0

Having a = unique URL is a different design (XAuth was more aligned with that idea).= =C2=A0

Fabien
=C2=A0=C2=A0
On Mon, = Nov 23, 2020 at 5:09 PM Dick Hardt <dick.hardt@gmail.com> wrote:
If all the access token is doing is expressing "please c= ontinue" ... why do we need an access token?

Why no= t just have a unique=C2=A0URL for the grant request? The URL is the identif= ier for the grant request that allows the client to delete, update, etc.

How the access token is being used is just like a co= okie. The AS gives a string to the client and the client must pass the stri= ng back to the AS when it calls it,=C2=A0the AS may then give a new string= =C2=A0to the client for the next call. Works like a cookie. I don't kno= w why you think there are legal issues around this.=C2=A0

/Dick



3D""=E1=90=A7

On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault &= lt;fabien.imbault@gmail.com> wrote:
Hi Dick,

In GNAP, the client isn't mana= ging state (unlike a web app), the entire point is that the lifecycle shoul= d be managed by the AS.=C2=A0

As in any state machine, there are states and transitions. Here we= 9;re not passing state, merely expressing "please continue". The = client can be completely unaware of the underlying state.=C2=A0
In effect the client onl= y has the ability to ask the server to generate the next transition.=

So I don't thin= k you can compare that to cookies. It's a different behavior. BTW if it= was the case it would lead to a whole new class of issues, because there&#= 39;s an entire legal framework around cookies...=C2=A0

To avoid confusion with a standard access to= ken, we have the "key" field. My proposal would be to make it mor= e explicitly (cf comment in issue 67).

Fabien=C2=A0


Le lun. 23 nov. 2020 =C3=A0 02:= 06, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit= =C2=A0:
When I look at how GNAP is using access tokens for continuati= on requests, and the pull request=C2=A0#129

Those "access tokens" = look a lot more like cookies (managing state) than how access tokens are us= ually used (representing authorization). See table below.

If there is a real requirement for passing state back and forth bet= ween a server (the AS in this case) and the client when making API calls, t= hen I suggest that is out of scope for GNAP as I see it being a general=C2= =A0purpose mechanism for any API.

/Dick

<= div>
cookies
- issued by server being accessed
-= are not presented to other servers
- issued after first access
- may= be different for different URLs
- may be updated on each access
- re= presents the context of a session (state)

access tokens
- = issued by an independent service (AS)
- may be used at any URL at the RS=
- new ones issued by AS as needed
- represents authorization granted= to a client at an RS
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
<= /blockquote>

--000000000000c40ce605b4ff31ba-- From nobody Thu Nov 26 03:40: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 6E59E3A124E for ; Thu, 26 Nov 2020 03:40:40 -0800 (PST) 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 ra2dbNn8YCD9 for ; Thu, 26 Nov 2020 03:40:37 -0800 (PST) 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 927D13A124D for ; Thu, 26 Nov 2020 03:40:37 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id a19so1552762ilm.3 for ; Thu, 26 Nov 2020 03:40:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A8I/4BZzjn0CRz0WTMxK1mXWuIBD/uSayEw7Zo1qfDg=; b=geBC0OY5Bqt3sJq4wBhljhFcMdD7EsCMQASdDW6gi286KHPX5AQrxUbGJWh9C7qIeN ELK0B8UlCPqT20zb8xzdRIw9LtelLIUF9sfLolZRu/7k9EpbzKNGx1ibEy1qd4rEko+l ufQrgYh3MQxTTz9ZQ9VuYi+Reuegy4OkA3V5ZiTWN5h0UKfgXviljbIiYUGFQQ3KatLU vm5vC5FWLKIJ6atUTZsusbguFIu52CCQiBLgLNaQCiFYhB0kxau0UC9gztKAsGdSUpaT I7rfmGNnrm7oJ28PlvT8rcUaavd/h7yzocC3E0fSdap8Hb0a8fpw9iCBryxzZe+ykNjS USvQ== 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=A8I/4BZzjn0CRz0WTMxK1mXWuIBD/uSayEw7Zo1qfDg=; b=XsNuQxcACRMjYLJ0eZEZng+JaKWn9z1Al/f+zt5bYysOPoUOPe+FWdnwsUeo1cRbI8 rleXfTMuizQybi9uFt49rM0JU4rc1dIahaL15KMssNp+OCGzGvV/y0t5WsAOahDPGPAN 3r9upOtFSwoViWveEcFweTxn+pYRJVlJMPkDDREZQ3ZW2qsUbgUjeQEc+dd3b8YfGVLx +jr4ePZ0xHw4k1ZCP/7Hd+jWldBOy28FoHeu/wINuU+M3HXkS7FtsIhf9ZnYeezRtLOE OBSdtKlftyxmAilDXNJ62hYIpZMR9yYzbDEoFTl496U5mABBLmSiNkSCExzqVJg4DkRw A7tA== X-Gm-Message-State: AOAM532W2hMxJmS09V7lsNGSZobtyxWMnV72Sn3EmoGwJLMAofyArQNq EBCl0s4vtgI5tSkidyqtUkcmp8vGYhXZ3AZI9wE= X-Google-Smtp-Source: ABdhPJxKCxx3A2hjYv4Mr7rfeQ/NE9KnB2hGhyxSnUbkKDyYkFY84VEdN6lB6v6kVWn3x3vCMRdYQf65sosic0t/KG4= X-Received: by 2002:a92:6b05:: with SMTP id g5mr2189242ilc.289.1606390836797; Thu, 26 Nov 2020 03:40:36 -0800 (PST) MIME-Version: 1.0 References: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> In-Reply-To: From: Fabien Imbault Date: Thu, 26 Nov 2020 12:40:25 +0100 Message-ID: To: Dick Hardt Cc: Yaron Sheffer , GNAP Mailing List , Aaron Parecki Content-Type: multipart/alternative; boundary="00000000000032a6cd05b50103d3" Archived-At: Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues 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, 26 Nov 2020 11:40:40 -0000 --00000000000032a6cd05b50103d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I hope you have a great Thanksgiving =F0=9F=A6=83 Regarding terminology: it's important work so that we all talk the same language and people understand the spec more easily. Ideally the editors (and the chairs I believe) would like to be able to consolidate consensus on terminology over a relatively short period of time, so that we can all focus on the core of the spec (a lot of work to do, and this shouldn't stop us from going forward). The suggested process is the following : 0) refer to issue 29 and the wiki for the latest state of discussion https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology (serves as a temporary consolidation of terms, before we can make a PR). It also provides guidance. This gives us a good starting point. A scenario could be that we chose to reuse the current terms (and update definitions), if we don't see concrete proposals that get positive support from the working group. That's the fallback strategy. But we'd like to start a phase where we open the discussion more broadly and see whether we can do better. *1) please send complete proposals on the mailing list, during the next 2 weeks. * Discussions on a single term won't be accepted at this point in time, the idea being that we'd like to start from a relatively coherent set of terms and definitions. Feel free also to comment on the mailing list on other people's proposals : do you agree? do you object? are there terms we should remove/add? (please be as factual as possible in your explanations). The more we can see consensus emerging at this stage the easier it will be. Please also have a look at "External sources", because we don't want to live in a vacuum. If existing definitions exist in our field, either reuse it if it fits our purpose, or explain why you need to change it. Please don't use a well-known term in a completely different way. *2) then the editors will propose a consolidated wiki * The editors will update the wiki, considering : - ideas and feedback sent on the mailing list, but also - consistency with the charter's objectives and the rest of the work. Depending on how it goes, we might already submit a PR (especially if we see a high level of agreement -> short track). Then we'll enter into the regular 1 week period to gather comments. Further discussion/explanations could be managed in a live interim IETF meeting (since this would be free, a maximum of people would be able to participate). At that stage, we should at least agree on the terms used, but their definitions might still change. *3) If required: focused/detailed issues on specific terms * We'll limit the time spent in this last step, with a defined deadline. *4) W6 Publish a PR and gather consensus for the duration of the work for the core spec * Then hopefully we can achieve consensus from the group. At that point we'll publish a new draft version with the changes, probably in sync with a formal IETF meeting (depends on how chairs/editors want to proceed, nothing has been defined yet, it's just a personal opinion). In addition to what will be displayed in the wiki, the PR will most probably change the structure of the document, to include a dedicated section for terminology. It will also update the rest of the document accordingly (editing work only). If new terminology requires specific design work, it shall be handled as separate issues, but doesn't preclude from including it already in the terminology. Example : suppose we'd want to separate the AS into a backend and a frontend (Interaction Server), we could introduce the term but the implications of that would have to be dealt separately. This example shows that terminology has potential broader impacts. 5) Before the final draft of the spec is published, I would expect a last review of the definitions at the end (but the terms wouldn't change), so that we make sure it is still up to date. Later, if extensions to the core spec require specific terms, we'll then be able to expand the terminology. To summarize, the goal of this process is to keep going forward, and avoid discussions that very possibly would never end otherwise. We feel it's very important to get that right in an early stage, so we hope you'll get involved in the process. Please comment on this process if needed. We're waiting for your contributions on the terminology for the next 2 weeks. Fabien ps : as highlighted by Dick, the editors have a PR running that concerns the [Client Instance]( https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132). This is linked to work being done on the core spec itself. We'll see if we need to adjust it as a result, but it doesn't preclude from making the current version more consistent. On Thu, Nov 26, 2020 at 12:15 AM Dick Hardt wrote: > What is the process for terminology? Some terms have issues, others don't= . > > I see a PR for changing RQ to CI -- but it is not clear where the > discussion for that, and other terms will be. > > =E1=90=A7 > > On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer > wrote: > >> Commenting on the proposed process (chair hat off): >> >> >> >> I think =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once so= mething is >> closed, we should be reasonably confident that it is resolved for good. >> People rarely search through closed issues. >> >> >> >> Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. I= nstead, I suggest >> to mark such issues with future milestones, e.g. =E2=80=9CIETF110=E2=80= =9D, meaning that at >> this time we will review the issue. Otherwise, the =E2=80=9Cpostponed=E2= =80=9D issues will >> probably suffer the destiny of all =E2=80=9Clow priority=E2=80=9D issues= =E2=80=93 they will be >> ignored for months and eventually closed en masse. See [1] for GitHub >> milestones. >> >> >> >> Otherwise I am fine with the rest of the process. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> [1] >> https://docs.github.com/en/free-pro-team@latest/github/managing-your-wor= k-on-github/about-milestones >> >> >> >> >> >> *From: *TXAuth on behalf of Aaron Parecki < >> aaron@parecki.com> >> *Date: *Wednesday, November 25, 2020 at 18:37 >> *To: *GNAP Mailing List >> *Subject: *[GNAP] GNAP Editors' Use of GitHub Issues >> >> >> >> The editors met yesterday to discuss the issues that were pulled out of >> the previous draft text and document a process for how to resolve these = and >> future issues. We would like to explain how we plan on using labels on >> GitHub issues to keep track of discussions and keep things moving. >> >> When there are substantive issues or pull requests, the editors will >> avoid merging or closing those outright, and instead mark them as >> "pending", so that these can be brought to the attention of the larger >> group. If no additional discussion happens on these, the merge or close >> action will be taken in 7 days. Note for this first round we are setting >> the deadline for the issues below as Dec 11th due to the US holiday and = the >> fact that this is the first time using this process. >> >> "Pending Merge" >> When specific text is proposed in a PR (by anyone, not limited to the >> editors), and the editors believe this text reflects the consensus of th= e >> working group, this marks that the PR will be merged in 7 days unless th= ere >> is a clear alternative proposal accepted by the working group. >> >> "Pending Close" >> When the editors believe an issue no longer needs discussion, we'll mark >> it "Pending Close". The issue will be closed in 7 days unless someone >> brings new information to the discussion. This tag is not applied to iss= ues >> that will be closed by a specific pull request. >> >> There are two additional labels we will use to flag issues to the group. >> >> "Needs Text" >> The editors suggest this issue needs additional text in the spec to >> clarify why this section is needed and under what circumstances. Without= a >> concrete proposal of text to be included in the spec, this section will = be >> removed in a future update. >> >> "Postponed" >> This issue can be reconsidered in the future with a more concrete >> discussion but is not targeted for immediate concrete changes to the spe= c >> text. When used on its own, this label does not indicate that an issue i= s >> targeted to be closed. An issue may also be marked "Pending Close", and >> this is used so that we can distinguish closed issues between discussion= s >> that have concluded or things that we may want to revisit in the future. >> Remember that closed issues are not deleted and their contents are still >> findable and readable, and that new issues can reference closed issues. >> >> With these labels in mind, here are the list of issues and their statuse= s >> we were able to discuss on our last editor's call. The action on these >> pending issues will be taken on Dec 11th to give the group enough time t= o >> review this list. For this first round, many of the issues are marked >> "Pending Close" as we're looking for low hanging fruit to prune the list= of >> issues down. In the future, you can expect to see more "Pending Merge" >> issues as we're bringing proposed text to review by the WG. >> >> Postponed: >> >> * Generic claim extension mechanism >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 >> >> Pending Merge: >> >> * Make access token mandatory for continuation API calls >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 >> >> Postponed and Pending Close: >> >> * Fetchable Keys >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 >> * Including OpenID Connect Claims >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 >> * Application communication with back-end >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 >> * Additional post-interaction protocols >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 >> >> Pending Close: >> >> * HTTP PUT vs POST for rotating access tokens >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 >> * Use of hash with unique callback URL >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 >> * Interaction considerations >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 >> * Expanding dynamic reference handles >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 >> * Post interaction callback nonce >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73 >> * Unique callback URIs >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 >> * Instance identifier >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 >> * Requesting resources by reference >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36 >> * Mapping resource references >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 >> >> --- >> >> Aaron Parecki >> >> https://aaronparecki.com >> >> >> >> -- 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 > --00000000000032a6cd05b50103d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,=C2=A0

<= /div>
I hope you have a great Thanksgiving=C2=A0=F0=9F=A6= =83

Regarding terminology: it's important work s= o that we all talk the=C2=A0same language and people understand the spec mo= re easily. Ideally the editors (and the chairs I believe) would like to be = able to consolidate consensus on terminology over a relatively short period= =C2=A0of time, so that we can all focus on the core of the spec (a lot of w= ork to do, and this shouldn't stop us from going forward).=C2=A0
<= div>
The suggested process is the following :=C2=A0

0) refer to issue 29 and the wiki for the latest state of d= iscussion
https://github.com/ietf-wg-gnap/gnap-core-protoc= ol/wiki/Terminology (serves as a temporary consolidation of terms, befo= re we can make a PR). It also provides guidance.=C2=A0

This gives us a good starting point. A scenario could be that we c= hose to reuse the current terms (and update definitions), if we don't s= ee concrete proposals that get positive support from the working group. Tha= t's the fallback strategy. But we'd like to start a phase where we = open the=C2=A0discussion more broadly and see whether we can do better.=C2= =A0

1) please send complete proposals on the ma= iling list, during the next 2 weeks.=C2=A0=C2=A0
Discussions = on a single term won't be accepted at this point in time, the idea bein= g that we'd like to start from a relatively coherent set of terms and d= efinitions.
Feel free also to comment on the mailing list on othe= r people's proposals : do you agree? do you object? are there terms we = should remove/add? (please be as factual as possible in your explanations).= =C2=A0
The more we can see consensus emerging at this stage the e= asier it will be.=C2=A0

Please also have a look=C2= =A0at "External sources", because we don't want to live in a = vacuum. If existing definitions exist in our field, either reuse it if it f= its our purpose, or explain why you need to change it. Please don't use= a well-known term in a completely different way.=C2=A0

<= /div>
2) then the editors will propose a consolidated wiki=C2=A0=
The editors will update the wiki, considering :=C2=A0
= - ideas and feedback sent on the mailing list, but also
- consist= ency with the charter's objectives and the rest of the work.=C2=A0

Depending on how it goes, we might already submit a PR= (especially if we see a high level of agreement -> short track).
<= div>
Then we'll enter into the regular 1 week period to g= ather comments. Further discussion/explanations could be managed in a live = interim IETF meeting (since this would be free, a maximum of people would b= e able to participate).=C2=A0
At that stage, we should at least a= gree on the terms used, but their definitions might still change.

3) If required: focused/detailed issues on specific term= s=C2=A0
We'll limit the time spent in this last step,=C2= =A0with a defined deadline.

4) W6 Publish a PR = and gather consensus for the duration of the work for the core spec=C2=A0= =C2=A0
Then hopefully we can achieve consensus from the group= . At that point we'll publish a new=C2=A0draft version with the changes= ,=C2=A0probably in sync with a formal IETF meeting (depends on how chairs/e= ditors want to proceed, nothing has been defined yet, it's just a perso= nal opinion).

In addition to what will be disp= layed in the wiki, the PR will most probably change the structure of the do= cument, to include a dedicated section for terminology. It will also update= the rest of the document accordingly (editing work only).=C2=A0
<= div>
If new terminology requires specific design work, it sha= ll be handled as separate issues,=C2=A0but doesn't preclude from includ= ing it already in the terminology. Example : suppose we'd want to separ= ate the AS into a backend and a frontend (Interaction Server), we could int= roduce the term but the implications of that would have to be dealt separat= ely. This example shows that terminology has potential broader impacts.=C2= =A0 =C2=A0

5) Before the final draft of the spec i= s published, I would expect a last review of the definitions at the end (bu= t the terms wouldn't change), so that we make sure it is still up to da= te.=C2=A0
Later, if extensions to the core spec require specific = terms, we'll then be able to expand the terminology.=C2=A0
To summarize, the goal of this process is to keep going forwar= d, and avoid discussions that very possibly would never end otherwise. We f= eel it's very important to get that right in an early stage, so we hope= you'll get involved in the process.=C2=A0

Ple= ase comment on this process if needed.=C2=A0
We're waiting fo= r your contributions on the terminology for the next 2 weeks.=C2=A0

Fabien=C2=A0

ps : as highlighted= by Dick, the editors have a PR running that concerns the [Client Instance]= (ht= tps://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132). This is lin= ked to work being done on the core spec itself. We'll see if we need to= adjust it as a result, but it doesn't preclude from making the current= version more consistent.=C2=A0


On Thu, = Nov 26, 2020 at 12:15 AM Dick Hardt <dick.hardt@gmail.com> wrote:
What is the process for terminolo= gy? Some terms have issues, others don't.

I see a PR= for changing RQ to CI -- but it is not clear where the discussion for that= , and other terms will be.

3D""=E1=90= =A7

On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer <yaronf.ietf@gmail.com> = wrote:

Commenting on the proposed process (= chair hat off):

=C2=A0

I think =E2=80=9Cpostponed=E2=80=9D issues shou= ld not be closed. Once something is closed, we should be reasonably confide= nt that it is resolved for good. People rarely search through closed issues= .

=C2=A0

Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D is not a= ctionable. Instead, I suggest to mark such issues with future milestones, e= .g. =E2=80=9CIETF110=E2=80=9D, meaning that at this time we will review the= issue. Otherwise, the =E2=80=9Cpostponed=E2=80=9D issues will probably suf= fer the destiny of all =E2=80=9Clow priority=E2=80=9D issues =E2=80=93 they= will be ignored for months and eventually closed en masse. See [1] for Git= Hub milestones.

=C2=A0

Otherwise I am fine with the rest of the proces= s.

=C2=A0

Thanks,

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

=C2=A0

<= p class=3D"MsoNormal">[1] https://docs.github.com/en/free-pro-team@latest/github/managing-your= -work-on-github/about-milestones

=C2=A0

=C2=A0

From: TXAuth <txauth-bounces@ietf.org> on behalf of Aaro= n Parecki <aaron@= parecki.com>
Date: Wednesday, November 25, 2020 at 18:37To: GNAP Mailing List <txauth@ietf.org>
Subject: [GNAP] GNAP Editors= ' Use of GitHub Issues

=C2=A0

The editors met yesterday to discuss the issues tha= t were pulled out of the previous draft text and document a process for how= to resolve these and future issues. We would like to explain how we plan o= n using labels on GitHub issues to keep track of discussions and keep thing= s moving.

When there are substantive issues or pull requests, the ed= itors will avoid merging or closing those outright, and instead mark them a= s "pending", so that these can be brought to the attention of the= larger group. If no additional discussion happens on these, the merge or c= lose action will be taken in 7 days. Note for this first round we are setti= ng the deadline for the issues below as Dec 11th due to the US holiday and = the fact that this is the first time using this process.

"Pendi= ng Merge"
When specific text is proposed in a PR (by anyone, not li= mited to the editors), and the editors believe this text reflects the conse= nsus of the working group, this marks that the PR will be merged in 7 days = unless there is a clear alternative proposal accepted by the working group.=

"Pending Close"
When the editors believe an issue no l= onger needs discussion, we'll mark it "Pending Close". The is= sue will be closed in 7 days unless someone brings new information to the d= iscussion. This tag is not applied to issues that will be closed by a speci= fic pull request.

There are two additional labels we will use to fla= g issues to the group.

"Needs Text"
The editors suggest= this issue needs additional text in the spec to clarify why this section i= s needed and under what circumstances. Without a concrete proposal of text = to be included in the spec, this section will be removed in a future update= .

"Postponed"
This issue can be reconsidered in the fut= ure with a more concrete discussion but is not targeted for immediate concr= ete changes to the spec text. When used on its own, this label does not ind= icate that an issue is targeted to be closed. An issue may also be marked &= quot;Pending Close", and this is used so that we can distinguish close= d issues between discussions that have concluded or things that we may want= to revisit in the future. Remember that closed issues are not deleted and = their contents are still findable and readable, and that new issues can ref= erence closed issues.

With these labels in mind, here are the list o= f issues and their statuses we were able to discuss on our last editor'= s call. The action on these pending issues will be taken on Dec 11th to giv= e the group enough time to review this list. For this first round, many of = the issues are marked "Pending Close" as we're looking for lo= w hanging fruit to prune the list of issues down. In the future, you can ex= pect to see more "Pending Merge" issues as we're bringing pro= posed text to review by the WG.

Postponed:

* Generic claim ex= tension mechanism
** https://github.com/ietf-wg-gnap/gn= ap-core-protocol/issues/131

Pending Merge:

* Make access = token mandatory for continuation API calls
** https://git= hub.com/ietf-wg-gnap/gnap-core-protocol/pull/129

Postponed and P= ending Close:

* Fetchable Keys
** https://github.= com/ietf-wg-gnap/gnap-core-protocol/issues/47
* Including OpenID Con= nect Claims
** https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/64
* Application communication with back-end
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/8= 2
* Additional post-interaction protocols
** http= s://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83

Pending= Close:
=C2=A0 =C2=A0
* HTTP PUT vs POST for rotating access tokens<= br>** https://github.com/ietf-wg-gnap/gnap-core-protocol/i= ssues/100
* Use of hash with unique callback URL
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84
* In= teraction considerations
** https://github.com/ietf-wg-g= nap/gnap-core-protocol/issues/81
* Expanding dynamic reference handl= es
** https://github.com/ietf-wg-gnap/gnap-core-protocol= /issues/76
* Post interaction callback nonce
** h= ttps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73
* Unique= callback URIs
** https://github.com/ietf-wg-gnap/gnap-= core-protocol/issues/55
* Instance identifier
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46
* Reque= sting resources by reference
** https://github.com/ietf-= wg-gnap/gnap-core-protocol/issues/36
* Mapping resource references** https://github.com/ietf-wg-gnap/gnap-core-protocol/iss= ues/35

---<= u>

Aaron Parecki

=C2=A0

-- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listin= fo/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
--00000000000032a6cd05b50103d3-- From nobody Fri Nov 27 01:03: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 A7FDA3A1524 for ; Fri, 27 Nov 2020 01:03:40 -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 oTvW_qUL4H56 for ; Fri, 27 Nov 2020 01:03:38 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 0D6DA3A0F4D for ; Fri, 27 Nov 2020 01:03:38 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id t13so4009653ilp.2 for ; Fri, 27 Nov 2020 01:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w9hzlWdTutLYdB7h/DJYI85SZ4es7W13gebGzGlNIDA=; b=cEyHgog950/PEQ8Inq9jHxtwySgf76a9SgmZVeMaSXHGfc9h18uJc0BWedJIUa5bdQ /KaehakaJfoplf1LkQpZhKarGV5+N8idFPyLHvj1AYv5T6gtMOc2IbLZYar1Bv/iwCIP r+f5hvOotdvyL3uc+xFjirG5MNKNuLeJtM7s5OStiipgLadWdhUwW33N6FPpmFGG6nT9 n4PO4mpkJVH9CH8+zHs7REGbIWMcPXaLYnOiJdVsDAj5xlO1iAB6F1tAY7JbYITUQalF ky/XldNK083GijWf4y67FeM0io82FbJpel+AY//Ffz5CNwOq3lxpysT75aEgCQc4WDtR OCeQ== 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=w9hzlWdTutLYdB7h/DJYI85SZ4es7W13gebGzGlNIDA=; b=VLw3vNRNO7FImIpC5BQAuRKQ+AfaKv0bPPgBV5LSX9lDBcK2WKVpZ+ns/Yj+YuSiv7 UBV6cuo48lz5t8Zfu+sA8ufyxlDBUlbrep18yoKqNvqprn9AlrE1z4UC8xFEY1Wx5sHV nId4CP8B/8ARYVTiE9ye1Ep/hnpS/U3jQACXYW82kArYy0iAzDSb88zQ+DECYXDg7ugF E7XNwFg3xq1nquMY2ZY39zsiOlvoU72DuNcvfTahIwHLNcxCYmORNBQr5p1w/SS+xyTK iDUmTZfFtS0hes30dU0G/ucc/dDZ99DjPdZVTgE/ebEeZk2kTmCUSKQQlgJX1GToDjAi +9/A== X-Gm-Message-State: AOAM533TS4AZtJxF1jHGFHEswYt1knyLm1087NENMBuiYFuFClSdiZJL UPoJDwK266r89FfFpwe1nx5JNDKXalC+US7Wqpk= X-Google-Smtp-Source: ABdhPJzSISb7EJXl67WH3qRxBtqZy0tG2qETp83rwD8GapI3+tIJMv7YnDYjwc5tBX1E6V2pjwVkWivn2+3h10UrfHg= X-Received: by 2002:a92:d489:: with SMTP id p9mr5768630ilg.123.1606467817298; Fri, 27 Nov 2020 01:03:37 -0800 (PST) MIME-Version: 1.0 References: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> In-Reply-To: From: Fabien Imbault Date: Fri, 27 Nov 2020 10:03:26 +0100 Message-ID: To: Tom Jones Cc: Yaron Sheffer , GNAP Mailing List , Aaron Parecki Content-Type: multipart/alternative; boundary="00000000000097e03e05b512efc6" Archived-At: Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues 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, 27 Nov 2020 09:03:41 -0000 --00000000000097e03e05b512efc6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, One of the potential problems we'd like to avoid is to have an ever growing list of open issues that we never close. The idea of having milestones (e.g. IETF110) might be a complementary way of managing priorities. Editors will revert back to the list after the US vacation days. Cheers, Fabien On Thu, Nov 26, 2020 at 1:26 AM Tom Jones wrote: > i agree - drop postponed - if you can't say till when, then close. Issues > can always be added by anyone at anytime. > Peace ..tom > > > On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer > wrote: > >> Commenting on the proposed process (chair hat off): >> >> >> >> I think =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once so= mething is >> closed, we should be reasonably confident that it is resolved for good. >> People rarely search through closed issues. >> >> >> >> Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. I= nstead, I suggest >> to mark such issues with future milestones, e.g. =E2=80=9CIETF110=E2=80= =9D, meaning that at >> this time we will review the issue. Otherwise, the =E2=80=9Cpostponed=E2= =80=9D issues will >> probably suffer the destiny of all =E2=80=9Clow priority=E2=80=9D issues= =E2=80=93 they will be >> ignored for months and eventually closed en masse. See [1] for GitHub >> milestones. >> >> >> >> Otherwise I am fine with the rest of the process. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> [1] >> https://docs.github.com/en/free-pro-team@latest/github/managing-your-wor= k-on-github/about-milestones >> >> >> >> >> >> *From: *TXAuth on behalf of Aaron Parecki < >> aaron@parecki.com> >> *Date: *Wednesday, November 25, 2020 at 18:37 >> *To: *GNAP Mailing List >> *Subject: *[GNAP] GNAP Editors' Use of GitHub Issues >> >> >> >> The editors met yesterday to discuss the issues that were pulled out of >> the previous draft text and document a process for how to resolve these = and >> future issues. We would like to explain how we plan on using labels on >> GitHub issues to keep track of discussions and keep things moving. >> >> When there are substantive issues or pull requests, the editors will >> avoid merging or closing those outright, and instead mark them as >> "pending", so that these can be brought to the attention of the larger >> group. If no additional discussion happens on these, the merge or close >> action will be taken in 7 days. Note for this first round we are setting >> the deadline for the issues below as Dec 11th due to the US holiday and = the >> fact that this is the first time using this process. >> >> "Pending Merge" >> When specific text is proposed in a PR (by anyone, not limited to the >> editors), and the editors believe this text reflects the consensus of th= e >> working group, this marks that the PR will be merged in 7 days unless th= ere >> is a clear alternative proposal accepted by the working group. >> >> "Pending Close" >> When the editors believe an issue no longer needs discussion, we'll mark >> it "Pending Close". The issue will be closed in 7 days unless someone >> brings new information to the discussion. This tag is not applied to iss= ues >> that will be closed by a specific pull request. >> >> There are two additional labels we will use to flag issues to the group. >> >> "Needs Text" >> The editors suggest this issue needs additional text in the spec to >> clarify why this section is needed and under what circumstances. Without= a >> concrete proposal of text to be included in the spec, this section will = be >> removed in a future update. >> >> "Postponed" >> This issue can be reconsidered in the future with a more concrete >> discussion but is not targeted for immediate concrete changes to the spe= c >> text. When used on its own, this label does not indicate that an issue i= s >> targeted to be closed. An issue may also be marked "Pending Close", and >> this is used so that we can distinguish closed issues between discussion= s >> that have concluded or things that we may want to revisit in the future. >> Remember that closed issues are not deleted and their contents are still >> findable and readable, and that new issues can reference closed issues. >> >> With these labels in mind, here are the list of issues and their statuse= s >> we were able to discuss on our last editor's call. The action on these >> pending issues will be taken on Dec 11th to give the group enough time t= o >> review this list. For this first round, many of the issues are marked >> "Pending Close" as we're looking for low hanging fruit to prune the list= of >> issues down. In the future, you can expect to see more "Pending Merge" >> issues as we're bringing proposed text to review by the WG. >> >> Postponed: >> >> * Generic claim extension mechanism >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 >> >> Pending Merge: >> >> * Make access token mandatory for continuation API calls >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 >> >> Postponed and Pending Close: >> >> * Fetchable Keys >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 >> * Including OpenID Connect Claims >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 >> * Application communication with back-end >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 >> * Additional post-interaction protocols >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 >> >> Pending Close: >> >> * HTTP PUT vs POST for rotating access tokens >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 >> * Use of hash with unique callback URL >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 >> * Interaction considerations >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 >> * Expanding dynamic reference handles >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 >> * Post interaction callback nonce >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73 >> * Unique callback URIs >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 >> * Instance identifier >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 >> * Requesting resources by reference >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36 >> * Mapping resource references >> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 >> >> --- >> >> Aaron Parecki >> >> https://aaronparecki.com >> >> >> >> -- 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 > --00000000000097e03e05b512efc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,=C2=A0

One of the potential pr= oblems we'd like to avoid is to have an ever growing list of open issue= s that we never close.=C2=A0

The idea of having mi= lestones (e.g. IETF110) might be a complementary way of managing priorities= .

Editors=C2=A0will revert back to the list after = the US vacation days.

Cheers,
Fabien

On Thu, Nov 26, 2020 at 1:26 AM Tom Jones <thomasclinganjones@gmail.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 agree -= drop postponed=C2=A0- if you can't say till when, then close. Issues c= an always be added by anyone at anytime.
Peace ..tom

On Wed, N= ov 25, 2020 at 10:27 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Commenting on the proposed process (chair hat off):<= /u>

=C2=A0

I think =E2=80=9Cpostponed=E2=80=9D issues should not be closed. O= nce something is closed, we should be reasonably confident that it is resol= ved for good. People rarely search through closed issues.

=

=C2=A0

Moreo= ver, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. Instead, = I suggest to mark such issues with future milestones, e.g. =E2=80=9CIETF110= =E2=80=9D, meaning that at this time we will review the issue. Otherwise, t= he =E2=80=9Cpostponed=E2=80=9D issues will probably suffer the destiny of a= ll =E2=80=9Clow priority=E2=80=9D issues =E2=80=93 they will be ignored for= months and eventually closed en masse. See [1] for GitHub milestones.

=C2=A0

Otherwise I am fine with the rest of the process.

=

=C2=A0

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

=C2=A0

[1] https://doc= s.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/ab= out-milestones

=C2=A0=

=C2=A0

From: TXAuth <txauth-bounces@ietf.org> on behalf of Aaron Parecki <aaron@parecki.com>= ;
Date: Wednesday, November 25, 2020 at 18:37
To: GNAP = Mailing List <txaut= h@ietf.org>
Subject: [GNAP] GNAP Editors' Use of GitHu= b Issues

= =C2=A0

The editors met yesterday to discuss the issues that were pulled out o= f the previous draft text and document a process for how to resolve these a= nd future issues. We would like to explain how we plan on using labels on G= itHub issues to keep track of discussions and keep things moving.

Wh= en there are substantive issues or pull requests, the editors will avoid me= rging or closing those outright, and instead mark them as "pending&quo= t;, so that these can be brought to the attention of the larger group. If n= o additional discussion happens on these, the merge or close action will be= taken in 7 days. Note for this first round we are setting the deadline for= the issues below as Dec 11th due to the US holiday and the fact that this = is the first time using this process.

"Pending Merge"
W= hen specific text is proposed in a PR (by anyone, not limited to the editor= s), and the editors believe this text reflects the consensus of the working= group, this marks that the PR will be merged in 7 days unless there is a c= lear alternative proposal accepted by the working group.

"Pendi= ng Close"
When the editors believe an issue no longer needs discuss= ion, we'll mark it "Pending Close". The issue will be closed = in 7 days unless someone brings new information to the discussion. This tag= is not applied to issues that will be closed by a specific pull request.
There are two additional labels we will use to flag issues to the gro= up.

"Needs Text"
The editors suggest this issue needs a= dditional text in the spec to clarify why this section is needed and under = what circumstances. Without a concrete proposal of text to be included in t= he spec, this section will be removed in a future update.

"Post= poned"
This issue can be reconsidered in the future with a more con= crete discussion but is not targeted for immediate concrete changes to the = spec text. When used on its own, this label does not indicate that an issue= is targeted to be closed. An issue may also be marked "Pending Close&= quot;, and this is used so that we can distinguish closed issues between di= scussions that have concluded or things that we may want to revisit in the = future. Remember that closed issues are not deleted and their contents are = still findable and readable, and that new issues can reference closed issue= s.

With these labels in mind, here are the list of issues and their = statuses we were able to discuss on our last editor's call. The action = on these pending issues will be taken on Dec 11th to give the group enough = time to review this list. For this first round, many of the issues are mark= ed "Pending Close" as we're looking for low hanging fruit to = prune the list of issues down. In the future, you can expect to see more &q= uot;Pending Merge" issues as we're bringing proposed text to revie= w by the WG.

Postponed:

* Generic claim extension mechanism** https://github.com/ietf-wg-gnap/gnap-core-protocol/is= sues/131

Pending Merge:

* Make access token mandatory for= continuation API calls
** https://github.com/ietf-wg-gna= p/gnap-core-protocol/pull/129

Postponed and Pending Close:
* Fetchable Keys
** https://github.com/ietf-wg-gnap/gn= ap-core-protocol/issues/47
* Including OpenID Connect Claims
** <= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64" tar= get=3D"_blank">https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64=
* Application communication with back-end
** htt= ps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82
* Addition= al post-interaction protocols
** https://github.com/ietf= -wg-gnap/gnap-core-protocol/issues/83

Pending Close:
=C2=A0 = =C2=A0
* HTTP PUT vs POST for rotating access tokens
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100
*= Use of hash with unique callback URL
** https://github.= com/ietf-wg-gnap/gnap-core-protocol/issues/84
* Interaction consider= ations
** https://github.com/ietf-wg-gnap/gnap-core-prot= ocol/issues/81
* Expanding dynamic reference handles
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76* Post interaction callback nonce
** https://github.co= m/ietf-wg-gnap/gnap-core-protocol/issues/73
* Unique callback URIs <= br>** https://github.com/ietf-wg-gnap/gnap-core-protocol/is= sues/55
* Instance identifier
** https://github.c= om/ietf-wg-gnap/gnap-core-protocol/issues/46
* Requesting resources = by reference
** https://github.com/ietf-wg-gnap/gnap-cor= e-protocol/issues/36
* Mapping resource references
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35

---

Aaron Parecki

= =C2=A0

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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000097e03e05b512efc6-- From nobody Sat Nov 28 23:41: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 18DDD3A12B1 for ; Sat, 28 Nov 2020 23:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=Q2NIdn4X; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AklnJd6P Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hvBPvZ5p7XC for ; Sat, 28 Nov 2020 23:41:14 -0800 (PST) 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 DEB763A12B5 for ; Sat, 28 Nov 2020 23:41:13 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AF1E85C004D for ; Sun, 29 Nov 2020 02:32:47 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 29 Nov 2020 02:32:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=+B2i9b+73CTiixtJDhTBcPc5tjX8H8vYQFdYW0f9T2s=; b=Q2NIdn4X Fn8y5DpIEVEGVsHuZgsbNRQ5MVUpW6kJCmqhr2M8DllG1YwKxr1CjWyOvOszE0jD 3vlgXCpiYiK8SsjciNO6rK2bLkfmErSJcbJ8k2/HhN5e6d+f0TFKbMcgN0Y1CnN7 wg10FG9C8f6VShOongv+n71Ap1jf6gCX7O6cY8/Ml6p2EMRmg2uNbn8L982X5NjF abnR7lGii9MowXWtO/BazdfyZ0vBeSpeIj616c3gr7KDQH2417HTvQs+5UzZaoGq lCrarSfrGy12DV3UHx9ls30sq3pMfCA/oeuvnpu0at5XA3qwbpOy4S3d3abN7Z7k RH6gtU1vvQXLHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=+B2i9b+73CTiixtJDhTBcPc5tjX8H 8vYQFdYW0f9T2s=; b=AklnJd6P74rSEAa+OXKIf8PF0tlJ+XAH98/e0WqUcIOVM ic20AmiOqGEt+jcACqV46yhNAphxeASG+NfKh+LyPs7B32NttxyEWY7Oy06sDkcF RaivVlqIGYfrHngECtU2tbiRQKTEDZ6As2YRu/LI60xTl01j+LLZm7i8IaIZqRlW w1JLT/pShkIjGFrawju0/rX5gByAE8js29YbKVNoka9h9O8E89il9oGXtc9MiHuh uZMxC5gvFY+ZQ79GZyLM4gGo5eKdF/frhzWfE04NjhtZOMU3xy0Z8GpMK8qPRv1l b86BtVXWhiSTjOtIr8wlQCL37iClxyZz3Lvcr9SGw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehjedguddtlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrjedtrdejuddrud ekkeenucevlhhushhtvghrufhiiigvpeehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az184-108.internal.cloudapp.net (unknown [40.70.71.188]) by mail.messagingengine.com (Postfix) with ESMTPA id 7271E3064AA6 for ; Sun, 29 Nov 2020 02:32:47 -0500 (EST) Content-Type: multipart/alternative; boundary="===============5209598778877266546==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20201129073247.7271E3064AA6@mailuser.nyi.internal> Date: Sun, 29 Nov 2020 02:32:47 -0500 (EST) 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, 29 Nov 2020 07:41:17 -0000 --===============5209598778877266546== 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 (+2/-0/=F0=9F=92=AC38) 2 issues created: - Generic claim extension mecanism (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131=20 - Refactor key presentation (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/130=20 20 issues received 38 new comments: - #131 Generic claim extension mecanism (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131=20 - #130 Refactor key presentation (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/130=20 - #100 HTTP PUT vs POST for rotating access tokens (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 [Pending = Close]=20 - #99 Updating and reading access tokens (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/99=20 - #98 Reading the state of a request (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/98=20 - #84 Use of hash with unique callback URL (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84=20 - #83 Additional post-interaction protocols (3 by jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 [Pending C= lose] [Postponed]=20 - #82 Application communication with back-end (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 [Pending C= lose] [Postponed]=20 - #81 Interaction considerations (2 by jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 [Pending C= lose]=20 - #76 Expanding dynamic reference handles (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 [Pending C= lose]=20 - #73 Post interaction callback nonce (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73=20 - #67 Continuation API artifact structure (10 by aaronpk, dickhardt, fimb= ault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/67=20 - #66 Continuation access token use outside of continuation requests (2 b= y jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/66=20 - #64 Including OpenID Connect claims (2 by aaronpk, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 [Pending C= lose] [Postponed]=20 - #55 Unique callback URIs (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 [Pending C= lose]=20 - #47 Fetchable keys (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 [Pending C= lose] [Postponed]=20 - #46 Instance Identifier (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 [Pending C= lose]=20 - #36 Requesting resources by reference (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36=20 - #35 Mapping resource references (3 by jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 [Pending C= lose]=20 - #29 Terminology (3 by dickhardt, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+1/-0/=F0=9F=92=AC1) 1 pull requests submitted: - Changed "resource client (RC)" to "client instance (CI)" (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132=20 1 pull requests received 1 new comments: - #129 Make access token mandatory for continuation API calls. (1 by jric= her) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 [Pending Me= rge]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============5209598778877266546== 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 November 29, 2020

Events without label "editorial"

Issues

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

2 issues created:

20 issues received 38 new comments:

Pull requests

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

1 pull requests submitted:

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============5209598778877266546==-- From nobody Mon Nov 30 09:29: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 CFC053A0EF9 for ; Mon, 30 Nov 2020 09:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zEvq-iOle_iR for ; Mon, 30 Nov 2020 09:29:11 -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 BD6713A0EEF for ; Mon, 30 Nov 2020 09:29:10 -0800 (PST) Received: from [192.168.1.19] (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 0AUHT7Z0020889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Nov 2020 12:29:08 -0500 From: Justin Richer Message-Id: <505DC510-2210-4097-AAFC-B321992555DA@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_78043C3F-8674-4C93-B3AE-8D1E26EDFD0C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 30 Nov 2020 12:29:07 -0500 In-Reply-To: Cc: Tom Jones , Yaron Sheffer , GNAP Mailing List , Aaron Parecki To: Fabien Imbault References: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues 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: Mon, 30 Nov 2020 17:29:16 -0000 --Apple-Mail=_78043C3F-8674-4C93-B3AE-8D1E26EDFD0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 With the editor hat on: A new spec like this is exciting work, and it=E2=80=99s inevitably going = to bring in lots of ideas of what it could do and what it could = incorporate. These ideas are extremely valuable as they are what push = new work into the realms of innovation and possibility and out of the = status quo from which it sprang. But there=E2=80=99s a downside to this = stream of ideas: most of them aren=E2=80=99t solid enough to incorporate = in any way. They=E2=80=99re just loose ideas that maybe we want to = consider, but they don=E2=80=99t have anything we can turn to and say = =E2=80=9Cwe should build that=E2=80=9D or =E2=80=9Cwe shouldn=E2=80=99t = build that=E2=80=9D since there isn=E2=80=99t any =E2=80=9Cthat=E2=80=9D = to build.=20 The editors have found that many of the issues currently filed seem to = fit into this category. There might be an interesting idea in there, but = without something specific to tie the idea to, we don=E2=80=99t have a = lot to work with as editors, and there are a lot of other items that the = group needs to decide and fix first. It=E2=80=99s an issue of triage. The goal of the =E2=80=9CPostponed=E2=80=9D tag, as I understand how = we=E2=80=99re using it, is to tag issues that might need some future = discussion, but we aren=E2=80=99t there yet. Something tagged as = =E2=80=9CPostponed=E2=80=9D but left open long term was meant to flag it = as an important detail we should get back to, when we can. Something = tagged =E2=80=9CPostponed=E2=80=9D and closed was meant to flag it as = something we might want to revisit, but only when we=E2=80=99ve got = something concrete to work against. It=E2=80=99s not meant to say that = the group has decided not to do it, it=E2=80=99s meant as a way to = acknowledge the input and potentially tie back to it in the future, even = if the issue got closed. It seems like the terminology of =E2=80=9CPostponed=E2=80=9D didn=E2=80=99= t quite capture that intent, and honestly it might not be the best tool = for us to use here. I think we we can work with the idea of IETF = meeting-based milestones, as has been suggested by several people. The = important outcome is that we don=E2=80=99t create a process that=E2=80=99s= susceptible to getting buried in =E2=80=9Cwouldn=E2=80=99t it be nice = if=E2=80=A6=E2=80=9D sentiments to the detriment of forward progress on = a functioning protocol. Right now, we=E2=80=99ve got a lot of items that = amount to possible future branches, and while we shouldn=E2=80=99t = simple forget them, we shouldn=E2=80=99t be focusing energy on them = until someone is able to take the effort to explore that branch. At such = a time, we can open a new issue and PR=E2=80=99s for that, and link back = to these historical artifacts for background and context. By tying such = issues to an IETF meeting milestone, we can put some boundaries on items = to keep them from languishing. When the milestone comes up, we can = evaluate if there=E2=80=99s something to look at yet or not. =E2=80=94 Justin > On Nov 27, 2020, at 4:03 AM, Fabien Imbault = wrote: >=20 > Hi there,=20 >=20 > One of the potential problems we'd like to avoid is to have an ever = growing list of open issues that we never close.=20 >=20 > The idea of having milestones (e.g. IETF110) might be a complementary = way of managing priorities. >=20 > Editors will revert back to the list after the US vacation days. >=20 > Cheers, > Fabien >=20 > On Thu, Nov 26, 2020 at 1:26 AM Tom Jones = > = wrote: > i agree - drop postponed - if you can't say till when, then close. = Issues can always be added by anyone at anytime. > Peace ..tom >=20 >=20 > On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer > wrote: > Commenting on the proposed process (chair hat off): >=20 > =20 >=20 > I think =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once = something is closed, we should be reasonably confident that it is = resolved for good. People rarely search through closed issues. >=20 > =20 >=20 > Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. = Instead, I suggest to mark such issues with future milestones, e.g. = =E2=80=9CIETF110=E2=80=9D, meaning that at this time we will review the = issue. Otherwise, the =E2=80=9Cpostponed=E2=80=9D issues will probably = suffer the destiny of all =E2=80=9Clow priority=E2=80=9D issues =E2=80=93 = they will be ignored for months and eventually closed en masse. See [1] = for GitHub milestones. >=20 > =20 >=20 > Otherwise I am fine with the rest of the process. >=20 > =20 >=20 > Thanks, >=20 > Yaron >=20 > =20 >=20 > [1] = https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-= on-github/about-milestones = > =20 >=20 > =20 >=20 > From: TXAuth > on behalf of Aaron Parecki = > > Date: Wednesday, November 25, 2020 at 18:37 > To: GNAP Mailing List > > Subject: [GNAP] GNAP Editors' Use of GitHub Issues >=20 > =20 >=20 > The editors met yesterday to discuss the issues that were pulled out = of the previous draft text and document a process for how to resolve = these and future issues. We would like to explain how we plan on using = labels on GitHub issues to keep track of discussions and keep things = moving. >=20 > When there are substantive issues or pull requests, the editors will = avoid merging or closing those outright, and instead mark them as = "pending", so that these can be brought to the attention of the larger = group. If no additional discussion happens on these, the merge or close = action will be taken in 7 days. Note for this first round we are setting = the deadline for the issues below as Dec 11th due to the US holiday and = the fact that this is the first time using this process. >=20 > "Pending Merge" > When specific text is proposed in a PR (by anyone, not limited to the = editors), and the editors believe this text reflects the consensus of = the working group, this marks that the PR will be merged in 7 days = unless there is a clear alternative proposal accepted by the working = group. >=20 > "Pending Close" > When the editors believe an issue no longer needs discussion, we'll = mark it "Pending Close". The issue will be closed in 7 days unless = someone brings new information to the discussion. This tag is not = applied to issues that will be closed by a specific pull request. >=20 > There are two additional labels we will use to flag issues to the = group. >=20 > "Needs Text" > The editors suggest this issue needs additional text in the spec to = clarify why this section is needed and under what circumstances. Without = a concrete proposal of text to be included in the spec, this section = will be removed in a future update. >=20 > "Postponed" > This issue can be reconsidered in the future with a more concrete = discussion but is not targeted for immediate concrete changes to the = spec text. When used on its own, this label does not indicate that an = issue is targeted to be closed. An issue may also be marked "Pending = Close", and this is used so that we can distinguish closed issues = between discussions that have concluded or things that we may want to = revisit in the future. Remember that closed issues are not deleted and = their contents are still findable and readable, and that new issues can = reference closed issues. >=20 > With these labels in mind, here are the list of issues and their = statuses we were able to discuss on our last editor's call. The action = on these pending issues will be taken on Dec 11th to give the group = enough time to review this list. For this first round, many of the = issues are marked "Pending Close" as we're looking for low hanging fruit = to prune the list of issues down. In the future, you can expect to see = more "Pending Merge" issues as we're bringing proposed text to review by = the WG. >=20 > Postponed: >=20 > * Generic claim extension mechanism > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 = >=20 > Pending Merge: >=20 > * Make access token mandatory for continuation API calls > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 = >=20 > Postponed and Pending Close: >=20 > * Fetchable Keys > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 = > * Including OpenID Connect Claims > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 = > * Application communication with back-end > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 = > * Additional post-interaction protocols > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 = >=20 > Pending Close: > =20 > * HTTP PUT vs POST for rotating access tokens > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 = > * Use of hash with unique callback URL > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 = > * Interaction considerations > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 = > * Expanding dynamic reference handles > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 = > * Post interaction callback nonce > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73 = > * Unique callback URIs=20 > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 = > * Instance identifier > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 = > * Requesting resources by reference > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36 = > * Mapping resource references > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 = > --- >=20 > Aaron Parecki >=20 > https://aaronparecki.com > =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 = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_78043C3F-8674-4C93-B3AE-8D1E26EDFD0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 With = the editor hat on:

A = new spec like this is exciting work, and it=E2=80=99s inevitably going = to bring in lots of ideas of what it could do and what it could = incorporate. These ideas are extremely valuable as they are what push = new work into the realms of innovation and possibility and out of the = status quo from which it sprang. But there=E2=80=99s a downside to this = stream of ideas: most of them aren=E2=80=99t solid enough to incorporate = in any way. They=E2=80=99re just loose ideas that maybe we want to = consider, but they don=E2=80=99t have anything we can turn to and say = =E2=80=9Cwe should build that=E2=80=9D or =E2=80=9Cwe shouldn=E2=80=99t = build that=E2=80=9D since there isn=E2=80=99t any =E2=80=9Cthat=E2=80=9D = to build. 

The editors have found that many of the issues currently = filed seem to fit into this category. There might be an interesting idea = in there, but without something specific to tie the idea to, we don=E2=80=99= t have a lot to work with as editors, and there are a lot of other items = that the group needs to decide and fix first. It=E2=80=99s an issue of = triage.

The = goal of the =E2=80=9CPostponed=E2=80=9D tag, as I understand how we=E2=80=99= re using it, is to tag issues that might need some future discussion, = but we aren=E2=80=99t there yet. Something tagged as =E2=80=9CPostponed=E2= =80=9D but left open long term was meant to flag it as an important = detail we should get back to, when we can. Something tagged = =E2=80=9CPostponed=E2=80=9D and closed was meant to flag it as something = we might want to revisit, but only when we=E2=80=99ve got something = concrete to work against. It=E2=80=99s not meant to say that the group = has decided not to do it, it=E2=80=99s meant as a way to acknowledge the = input and potentially tie back to it in the future, even if the issue = got closed.

It = seems like the terminology of =E2=80=9CPostponed=E2=80=9D didn=E2=80=99t = quite capture that intent, and honestly it might not be the best tool = for us to use here. I think we we can work with the idea of IETF = meeting-based milestones, as has been suggested by several people. The = important outcome is that we don=E2=80=99t create a process that=E2=80=99s= susceptible to getting buried in =E2=80=9Cwouldn=E2=80=99t it be nice = if=E2=80=A6=E2=80=9D sentiments to the detriment of forward progress on = a functioning protocol. Right now, we=E2=80=99ve got a lot of items that = amount to possible future branches, and while we shouldn=E2=80=99t = simple forget them, we shouldn=E2=80=99t be focusing energy on them = until someone is able to take the effort to explore that branch. At such = a time, we can open a new issue and PR=E2=80=99s for that, and link back = to these historical artifacts for background and context. By tying such = issues to an IETF meeting milestone, we can put some boundaries on items = to keep them from languishing. When the milestone comes up, we can = evaluate if there=E2=80=99s something to look at yet or not.

 =E2=80=94 = Justin

On Nov 27, 2020, at 4:03 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi there, 

One of the potential problems we'd like = to avoid is to have an ever growing list of open issues that we never = close. 

The= idea of having milestones (e.g. IETF110) might be a complementary way = of managing priorities.

Editors will revert back to the list after the US = vacation days.

Cheers,
Fabien

On Thu, Nov 26, 2020 at 1:26 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
i agree - = drop postponed - if you can't say till when, then close. Issues can = always be added by anyone at anytime.
Peace ..tom


On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

Commenting on the proposed process = (chair hat off):

 

I think =E2=80=9Cpostponed=E2=80=9D issues should = not be closed. Once something is closed, we should be reasonably = confident that it is resolved for good. People rarely search through = closed issues.

 

Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D = is not actionable. Instead, I suggest to mark such issues with future = milestones, e.g. =E2=80=9CIETF110=E2=80=9D, meaning that at this time we = will review the issue. Otherwise, the =E2=80=9Cpostponed=E2=80=9D issues = will probably suffer the destiny of all =E2=80=9Clow priority=E2=80=9D = issues =E2=80=93 they will be ignored for months and eventually closed = en masse. See [1] for GitHub milestones.

 

Otherwise I am fine with the = rest of the process.

 

Thanks,

         =        Yaron

 

[1] https://docs.github.com/en/free-pro-team@latest/github/managing= -your-work-on-github/about-milestones

 

 

From: TXAuth <txauth-bounces@ietf.org> on behalf = of Aaron Parecki <aaron@parecki.com>
Date: Wednesday, November 25, 2020 at 18:37
To: GNAP Mailing List <txauth@ietf.org>
Subject: = [GNAP] GNAP Editors' Use of GitHub Issues

 

The editors met = yesterday to discuss the issues that were pulled out of the previous = draft text and document a process for how to resolve these and future = issues. We would like to explain how we plan on using labels on GitHub = issues to keep track of discussions and keep things moving.

When there are substantive issues or pull = requests, the editors will avoid merging or closing those outright, and = instead mark them as "pending", so that these can be brought to the = attention of the larger group. If no additional discussion happens on = these, the merge or close action will be taken in 7 days. Note for this = first round we are setting the deadline for the issues below as Dec 11th = due to the US holiday and the fact that this is the first time using = this process.

"Pending Merge"
When specific text is proposed in a PR (by anyone, not = limited to the editors), and the editors believe this text reflects the = consensus of the working group, this marks that the PR will be merged in = 7 days unless there is a clear alternative proposal accepted by the = working group.

"Pending Close"
When the editors believe an issue no longer needs discussion, = we'll mark it "Pending Close". The issue will be closed in 7 days unless = someone brings new information to the discussion. This tag is not = applied to issues that will be closed by a specific pull request.

There are two additional labels we will use to = flag issues to the group.

"Needs Text"
The editors suggest this issue needs additional text in the = spec to clarify why this section is needed and under what circumstances. = Without a concrete proposal of text to be included in the spec, this = section will be removed in a future update.

"Postponed"
This issue can be reconsidered in = the future with a more concrete discussion but is not targeted for = immediate concrete changes to the spec text. When used on its own, this = label does not indicate that an issue is targeted to be closed. An issue = may also be marked "Pending Close", and this is used so that we can = distinguish closed issues between discussions that have concluded or = things that we may want to revisit in the future. Remember that closed = issues are not deleted and their contents are still findable and = readable, and that new issues can reference closed issues.

With these labels in mind, here are the list = of issues and their statuses we were able to discuss on our last = editor's call. The action on these pending issues will be taken on Dec = 11th to give the group enough time to review this list. For this first = round, many of the issues are marked "Pending Close" as we're looking = for low hanging fruit to prune the list of issues down. In the future, = you can expect to see more "Pending Merge" issues as we're bringing = proposed text to review by the WG.

Postponed:

* Generic claim = extension mechanism
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131

Pending Merge:

* Make access token mandatory for continuation API calls
** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129=

Postponed and Pending Close:

* Fetchable Keys
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47
* Including OpenID Connect Claims
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64
* Application communication with back-end
**= https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82
* Additional post-interaction protocols
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83

Pending Close:
  =  
* HTTP PUT vs POST for rotating access tokens
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100
* Use of hash with unique callback URL
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84
* Interaction considerations
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81
* Expanding dynamic reference handles
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76
* Post interaction callback nonce
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73
* Unique callback URIs
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55
* Instance identifier
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46
* Requesting resources by reference
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36
* Mapping resource references
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35

---

Aaron = Parecki

https://aaronparecki.com

 

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

= --Apple-Mail=_78043C3F-8674-4C93-B3AE-8D1E26EDFD0C-- From nobody Mon Nov 30 11:20: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 62AB63A1081 for ; Mon, 30 Nov 2020 11:20:09 -0800 (PST) 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_KAM_HTML_FONT_INVALID=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 NeJbSIK3xStd for ; Mon, 30 Nov 2020 11:20:06 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB443A107D for ; Mon, 30 Nov 2020 11:20:05 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id z21so23807152lfe.12 for ; Mon, 30 Nov 2020 11:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l8YyoxONHs9FD24V9Cwz7lQWblCoKSPp0pG6AxPr00c=; b=kXH7RYsM05eBQoPSsa9ta4gnYv57sx1mkVdwtSwx1eX0QRBEO4uvcwjOLhIpZzhMwu NRirULS6x4uKy7y1l1h/5UgH/FD/X2iwEWwEi2yuacsSksRG2v5ktaOl0NKSWZ2JTL/C YQEJ0Duoh5AWvNHnRi7bnY6D25e9z7NQm6YXncz8ugmVufLOGR6fVxK9trp0JWixvO48 sSowAztCpK8KFIkBMQBD3nUaMt6R6ZxKgnJhiyh1Ulgh0FcMltjFalPjA3QJcNDHLpdH 54cgCtoljx+IOI6nM+JdwHqi3qEiHDNWCIC9OqYPR0f9WYrbjIor1jRD2DHizjO2hAtg a58w== 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=l8YyoxONHs9FD24V9Cwz7lQWblCoKSPp0pG6AxPr00c=; b=pK3v0AWOVdc2igucFEaHariMS0mUur9+v4ITrOlD6US8MyrhMPb8UDKuQfIvBKkS00 6xdTDnMQQY4WA6eRbDH+/LQk4zcqR9yT9so2VFgEavBBF1P5tMSf5RUykqLj7plmDl1k c5WUyFoZDDbosK0Qo3K7KNbOUg3uVlxYCqlHi4ycRojgDC5c7A2NWWrjhBZYwvxVZxpi W0Wt1VKlyQBeLQYLyAuCG8lGgV+UuvdHPPfXyb7BNhCtGTnPBPrAQpKz+1Cl6GcETxFU e7TRZVaS4jxruO4wTPK6iNly8tq9zw8tfNl5SH+RHIuzkMfD6r6EPjzvpDhOp9u8cET0 vmvA== X-Gm-Message-State: AOAM533YHwe0fj8fbwCbDn+9TlnYwrwyowPWWGKOnnYykc3PBKXeHY05 SWEfmHAwy64EhaWHCfIMDaj9bg1jJVSMT3R4nYw= X-Google-Smtp-Source: ABdhPJwZLyDZoTa23OyGfr5IozYKH/TH1HmeT5jvXWWGKy+Qy6HXb/t3jG0AUFB+Ah88uZmnC8agRxTPzvJzg84XDAg= X-Received: by 2002:a19:6e4c:: with SMTP id q12mr9740958lfk.162.1606764003292; Mon, 30 Nov 2020 11:20:03 -0800 (PST) MIME-Version: 1.0 References: <9D3D60CC-5019-4CC2-BE2D-4EF789FABE31@mit.edu> In-Reply-To: From: Dick Hardt Date: Mon, 30 Nov 2020 11:19:26 -0800 Message-ID: To: Fabien Imbault Cc: Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000a77db605b557e589" Archived-At: Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie 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: Mon, 30 Nov 2020 19:20:09 -0000 --000000000000a77db605b557e589 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Fabien: the issues 84 and 55 are unrelated. The issues you bring up are related to a unique callback URL provided by the client to the AS -- I am referring to the URL representing the grant request that is provided by the AS to the client. wrt issue 67 -- I'm proposing we NOT have an "access token" -- we keep it simple by having only a unique URL =E1=90=A7 On Thu, Nov 26, 2020 at 1:30 AM Fabien Imbault wrote: > Hi there, > > We have had several discussions that are related to your items, especiall= y > related to unique URLs: > > * Use of hash with unique callback URL > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 > > * Unique callback URIs > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 > > We tried to describe the rationale for the suggested choice as best we co= uld. Please comment on the issues if needed. > > As for issue 67 / PR 129, the general idea is to make use of access token= s (here also we explained why, but feel free to comment the PR, ideally I'd= like to review it after yours, so that I can take it into account). > > * Refactor key presentation > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/130 > > Fabien > > > On Wed, Nov 25, 2020 at 9:43 PM Fabien Imbault > wrote: > >> Couldn't say I agree here. >> >> Will send more info and explanations when I reopen my laptop tomorrow >> morning :-) >> >> Fabien >> >> Le mer. 25 nov. 2020 =C3=A0 21:37, Dick Hardt a = =C3=A9crit : >> >>> Would you share a link? I see the discussion on the access token pull >>> request, but no discussion on unique URLs. >>> >>> Do you agree with my assessment of the "access token"? >>> >>> =E1=90=A7 >>> >>> On Wed, Nov 25, 2020 at 12:33 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >>>> Hi Dick, >>>> >>>> There is more context on the rationale, from the comments the editors >>>> made to the issues yesterday. >>>> >>>> Especially the part on unique URLs. >>>> >>>> Best >>>> Fabien >>>> >>>> >>>> Le mer. 25 nov. 2020 =C3=A0 21:27, Dick Hardt a >>>> =C3=A9crit : >>>> >>>>> >>>>> There are numerous issues with the proposal: >>>>> >>>>> 1) It is not an "access token". Just because it is sent in the HTTP >>>>> Authorization header does not make it an access token. The client has >>>>> already authenticated before the "access token" is presented. The AS >>>>> already knows what the client is authorized to do at the AS before th= e >>>>> "access token" is issued, so it is not needed to represent authorizat= ion as >>>>> an access token is with an RS. The "access token" is serving the purp= ose >>>>> that the transaction handle served in the past -- the context of the >>>>> transaction. Per my earlier comments, this "access token" is more lik= e a >>>>> cookie. >>>>> >>>>> 2) Calling it an "access token" is changing the well known meaning of >>>>> an access token as used in OAuth. The client authenticates to the AS = APIs >>>>> in OAuth 2.0, it does not present an access token. Access tokens are >>>>> presented by a client to an RS to prove authorization. >>>>> >>>>> 3) What the client has to do with the "access token" is not the same >>>>> as access tokens for an RS. The client gets a new "access token" for = each >>>>> grant request, and for each API call to the AS, and the client learns= it >>>>> can not make any more API calls for that specific request when it doe= s not >>>>> get an "access token" back. This is a completely different design pat= tern >>>>> than calling an RS API with an access token, and is a new design patt= ern >>>>> for calling APIs. This adds complexity to the client that it would no= t >>>>> normally have, and I don't think GNAP is the right place to start a n= ew >>>>> design pattern. >>>>> >>>>> 4) Clients that only want claims from the AS and no access tokens wil= l >>>>> be required to support an API calling mechanism they would not have t= o >>>>> support otherwise. >>>>> >>>>> 5) If the AS does not provide an "access token", there is no mechanis= m >>>>> for a client to delete the request, as the client is not allowed to m= ake a >>>>> call without an "access token". >>>>> >>>>> 6) There is no standard identifier for the request. Debugging and >>>>> auditing are hampered by the client and AS having no standard way to >>>>> identifying a request. While one AS may provide a unique URL for each= grant >>>>> request, another AS may use a persistent "access token" to identify t= he >>>>> grant request, and other ASs may issue a new "access token" on each A= PI >>>>> call, providing no persistent identifier for the request. >>>>> >>>>> Representing each grant request with an unique URL has the following >>>>> advantages: >>>>> >>>>> 1) It follows the common REST like API model where each resource has = a >>>>> URI which is well understood. >>>>> >>>>> 2) There is only one way for a client and AS to identify a grant >>>>> request. >>>>> >>>>> 3) There is a standard, persistent unique identifier for the client >>>>> and AS to refer to a grant request. >>>>> >>>>> >>>>> FWIW: the statement that it is more "access token" like than a cookie >>>>> because it is bound to a key is untrue. Binding cookies to keys was t= he >>>>> motivation for RFC 8471 - The Token Binding Protocol Version 1.0. Hav= ing >>>>> the "access token" bound to a key provides no value as the AS already= knows >>>>> which client it is through client authentication. The only time that = would >>>>> not be the case is if the "access token" was self contained and the g= rant >>>>> request APIs were at an server independent of the AS where the origin= al >>>>> request was made. >>>>> >>>>> >>>>> >>>>> >>>>> =E1=90=A7 >>>>> >>>>> On Mon, Nov 23, 2020 at 9:55 AM Justin Richer wrote= : >>>>> >>>>>> An important distinction here is that the access tokens in question >>>>>> are always going to be bound to a key for presentation purposes, so = in many >>>>>> ways they are quite distinct from cookies. >>>>>> >>>>>> Since =E2=80=9Ccontinuation=E2=80=9D in its various forms is now an = API, why not >>>>>> treat it like other APIs the client would call and use access tokens= ? >>>>>> >>>>>> Apart from design choices, what is the negative cost of requiring an >>>>>> access token? >>>>>> >>>>>> We aren=E2=80=99t asking the client to do anything it=E2=80=99s not = already doing. >>>>>> Even if the client is going to use bearer tokens at a downstream RS,= the >>>>>> signature presentation mechanism for the bound access token at the >>>>>> continuation API is exactly the same as what the client used in the = first >>>>>> place to get the continuation response. >>>>>> >>>>>> We aren=E2=80=99t asking the AS to do anything special either since = it >>>>>> already needs to be able to validate the signature inbound, and it n= eeds to >>>>>> be able to reference an artifact for the ongoing request (stateful o= r not). >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Nov 23, 2020, at 12:44 PM, Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>> Yes. "Cookies were designed to be a reliable mechanism for websites >>>>>> to remember stateful i= nformation". >>>>>> We're not storing anything, it's just a reference. >>>>>> >>>>>> On Mon, Nov 23, 2020 at 6:38 PM Dick Hardt >>>>>> wrote: >>>>>> >>>>>>> To clarify, I am talking about HTTP cookies, which are effectively >>>>>>> opaque to the web browser, and used by the web server to store stat= e. >>>>>>> >>>>>>> https://en.wikipedia.org/wiki/HTTP_cookie >>>>>>> >>>>>>> A client may use local storage for saving state, but that is >>>>>>> completely different from an HTTP cookie which is issued by the ser= ver. >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> If the client was directly managing/storing its state, then it >>>>>>>> would indeed effectively work as a cookie. >>>>>>>> But here the access token merely provides a map to the current >>>>>>>> state (opaque to the client), as managed/controlled by the AS. >>>>>>>> It's a very different use case compared to what cookies are used >>>>>>>> for in webapps. >>>>>>>> >>>>>>>> Having a unique URL is a different design (XAuth was more aligned >>>>>>>> with that idea). >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt >>>>>>>> wrote: >>>>>>>> >>>>>>>>> If all the access token is doing is expressing "please continue" >>>>>>>>> ... why do we need an access token? >>>>>>>>> >>>>>>>>> Why not just have a unique URL for the grant request? The URL is >>>>>>>>> the identifier for the grant request that allows the client to de= lete, >>>>>>>>> update, etc. >>>>>>>>> >>>>>>>>> How the access token is being used is just like a cookie. The AS >>>>>>>>> gives a string to the client and the client must pass the string = back to >>>>>>>>> the AS when it calls it, the AS may then give a new string to the= client >>>>>>>>> for the next call. Works like a cookie. I don't know why you thin= k there >>>>>>>>> are legal issues around this. >>>>>>>>> >>>>>>>>> /Dick >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> =E1=90=A7 >>>>>>>>> >>>>>>>>> On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Dick, >>>>>>>>>> >>>>>>>>>> In GNAP, the client isn't managing state (unlike a web app), the >>>>>>>>>> entire point is that the lifecycle should be managed by the AS. >>>>>>>>>> >>>>>>>>>> As in any state machine, there are states and transitions. Here >>>>>>>>>> we're not passing state, merely expressing "please continue". Th= e client >>>>>>>>>> can be completely unaware of the underlying state. >>>>>>>>>> In effect the client only has the ability to ask the server to >>>>>>>>>> generate the next transition. >>>>>>>>>> >>>>>>>>>> So I don't think you can compare that to cookies. It's a >>>>>>>>>> different behavior. BTW if it was the case it would lead to a wh= ole new >>>>>>>>>> class of issues, because there's an entire legal framework aroun= d >>>>>>>>>> cookies... >>>>>>>>>> >>>>>>>>>> To avoid confusion with a standard access token, we have the >>>>>>>>>> "key" field. My proposal would be to make it more explicitly (cf= comment in >>>>>>>>>> issue 67). >>>>>>>>>> >>>>>>>>>> Fabien >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le lun. 23 nov. 2020 =C3=A0 02:06, Dick Hardt >>>>>>>>>> a =C3=A9crit : >>>>>>>>>> >>>>>>>>>>> When I look at how GNAP is using access tokens for continuation >>>>>>>>>>> requests, and the pull request #129 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Those "access tokens" look a lot more like cookies (managing >>>>>>>>>>> state) than how access tokens are usually used (representing >>>>>>>>>>> authorization). See table below. >>>>>>>>>>> >>>>>>>>>>> If there is a real requirement for passing state back and forth >>>>>>>>>>> between a server (the AS in this case) and the client when maki= ng API >>>>>>>>>>> calls, then I suggest that is out of scope for GNAP as I see it= being a >>>>>>>>>>> general purpose mechanism for any API. >>>>>>>>>>> >>>>>>>>>>> /Dick >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *cookies*- issued by server being accessed >>>>>>>>>>> - are not presented to other servers >>>>>>>>>>> - issued after first access >>>>>>>>>>> - may be different for different URLs >>>>>>>>>>> - may be updated on each access >>>>>>>>>>> - represents the context of a session (state) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *access tokens*- issued by an independent service (AS) >>>>>>>>>>> - may be used at any URL at the RS >>>>>>>>>>> - new ones issued by AS as needed >>>>>>>>>>> - represents authorization granted to a client at an RS >>>>>>>>>>> =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 >>>>>> >>>>>> >>>>>> --000000000000a77db605b557e589 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fabien: the issues 84 and 55 are unrelated.=C2=A0

=
The issues you bring up are related to a unique callback URL pro= vided by the client to the AS -- I am referring to the URL representing the= grant request that is provided by the AS to the client.

wrt issue 67 -- I'm proposing we NOT have an "access token&= quot; -- we keep it simple by having only a unique=C2=A0URL

<= /div>
=3D""=E1=90=A7

On Thu, Nov 26, 2020 at 1:30 AM Fabien = Imbault <fabien.imbault@gmai= l.com> wrote:
Hi there,=C2=A0

We have had severa= l discussions that are related to your items, especially related to unique = URLs:=C2=A0

* Use of hash with unique callback URL
** https=
://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84
* U=
nique callback URIs
** https=
://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55
We tried to describe the rationale for the suggested choice as =
best we could. Please comment on the issues if needed. 
As for issue 67 / PR 129, the general idea is to make use of access=
 tokens (here also we explained why, but feel free to comment the PR, ideal=
ly I'd like to review it after yours, so that I can take it into accoun=
t).  
* Refactor key presentation
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issu=
es/130 
Fabien

On Wed, Nov = 25, 2020 at 9:43 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
=
Couldn&= #39;t say I agree here.=C2=A0

= Will send more info and explanations when I reopen my laptop tomorrow morni= ng :-)

Fabien=C2=A0

Le mer. 25 nov. 2020 =C3=A0 21:37, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit= =C2=A0:
Would you share a link? I see the discussion on the access token p= ull request, but no discussion on unique URLs.

Do you ag= ree with my assessment of the "access token"?

3D"==E1=90=A7

On Wed, Nov 25, 2020 at 12:33 PM Fa= bien Imbault <fabien.imbault@gmail.com> wrote:
Hi Dick,
There is more context on the ra= tionale, from the comments the editors made to the issues yesterday.=C2=A0<= /div>

Especially the part on u= nique URLs.=C2=A0

Best= =C2=A0
Fabien=C2=A0


Le mer. 25 nov. = 2020 =C3=A0 21:27, Dick Hardt <dick.hardt@gmail.com> a =C3=A9cr= it=C2=A0:

There are numerous issues with the proposal:=

1) It is not an "access token". Just be= cause=C2=A0it is sent in the HTTP Authorization header does not make it an = access token. The client has already authenticated before the "access = token" is presented. The AS already knows what the client is authorize= d to do at the AS before the "access token" is issued, so it is n= ot=C2=A0needed to represent authorization as an access token is with an RS.= The "access token" is serving the purpose that the transaction h= andle=C2=A0served in the past --=C2=A0the context of the transaction. Per m= y earlier comments, this "access token" is more like a cookie.

2) Calling it an "access token" is changin= g=C2=A0the well known meaning of an access token as used in OAuth. The clie= nt authenticates to the AS APIs in OAuth 2.0, it does not present an access= token. Access tokens are presented by a client to an RS to prove authoriza= tion.=C2=A0

3) What the client has to do with the = "access token" is not the same as access tokens for an RS. The cl= ient gets a new "access token" for each grant request, and for ea= ch API call to the AS, and the client learns it can not make any more API c= alls for that specific request when it does not get an "access token&q= uot; back. This is a completely different design pattern than calling an RS= API with an access token,=C2=A0and is a new design pattern for calling API= s. This adds complexity to the client that it would not normally have, and = I don't think GNAP is the right place to start a new design pattern.

4) Clients that only want claims from the AS and no = access tokens will be required to support an API calling mechanism they wou= ld not have to support otherwise.=C2=A0

5) If the = AS does not provide an "access token", there is no mechanism for = a client to delete the request, as the client is not allowed to make a call= without an "access token".

6) There is = no standard identifier for the request. Debugging and auditing are hampered= by the client and AS having no standard way to identifying a request. Whil= e one AS may provide a unique URL for each grant request, another AS may us= e a persistent "access token" to identify the grant request, and = other ASs may=C2=A0issue a new "access token" on each API call, p= roviding no persistent identifier for the request.

Representing each grant request with an unique URL has the following advan= tages:

1) It follows the common REST like API mode= l where each resource has a URI which is well understood.

2) There is only one way for a client and AS to identify a grant re= quest.

3) There is a standard, persistent unique i= dentifier for the client and AS to refer to a grant request.

=

FWIW: the statement that it is more "access = token" like than a cookie because it is bound to a key is untrue. Bind= ing cookies to keys was the motivation for RFC 8471 - The Token Binding Pro= tocol Version 1.0. Having the "access token" bound to a key provi= des no value as the AS already knows which client it is through client auth= entication. The only time that would not be the case is if the "access= token" was self contained and the grant request APIs were at an serve= r independent=C2=A0of the AS where the original request was made.=C2=A0




3D""=E1=90=A7

On Mon, Nov 23, 2020 at 9:55 AM Justin Richer <<= a href=3D"mailto:jricher@mit.edu" rel=3D"noreferrer noreferrer" target=3D"_= blank">jricher@mit.edu> wrote:
An important distinction here is that the a= ccess tokens in question are always going to be bound to a key for presenta= tion purposes, so in many ways they are quite distinct from cookies.
<= div>
Since =E2=80=9Ccontinuation=E2=80=9D in its various form= s is now an API, why not treat it like other APIs the client would call and= use access tokens?

Apart from design choices, wha= t is the negative cost of requiring an access token?

We aren=E2=80=99t asking the client to do anything it=E2=80=99s not alre= ady doing. Even if the client is going to use bearer tokens at a downstream= RS, the signature presentation mechanism for the bound access token at the= continuation API is exactly the same as what the client used in the first = place to get the continuation response.=C2=A0

We a= ren=E2=80=99t asking the AS to do anything special either since it already = needs to be able to validate the signature inbound, and it needs to be able= to reference an artifact for the ongoing request (stateful or not).=C2=A0<= /div>

=C2=A0=E2=80=94 Justin

On Nov 23, 2020, at 12:44 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Yes. "Cookies were designed to be a reliable mechanism for web= sites to remember=C2=A0stateful=C2=A0information". We're no= t storing anything, it's just a reference.=C2=A0

On Mon, Nov 23, = 2020 at 6:38 PM Dick Hardt <dick.hardt@gmail.com> w= rote:
To clarify, I am talking about HTTP cookies, which are effect= ively opaque to the web browser,=C2=A0and used by the web server to store s= tate.


A client may use = local storage for saving=C2=A0state, but that is completely different from = an HTTP cookie which is issued by the server.
3D""=E1= =90=A7

On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
If the= client was directly managing/storing its state, then it would indeed effec= tively work as a cookie.=C2=A0
But here the access token mere= ly provides a map to the current state (opaque to the client), as managed/c= ontrolled by the AS.=C2=A0
It's a very different use case= compared to what cookies are used for in webapps.=C2=A0

Having a unique URL is a different design (XAuth was more aligned wi= th that idea).=C2=A0

Fabien
=C2=A0=C2=A0=

On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt <dick.hard= t@gmail.com> wrote:
If all the access token is doing is expressing = "please continue" ... why do we need an access token?

Why not just have a unique=C2=A0URL for the grant request? The URL = is the identifier for the grant request that allows the client to delete, u= pdate, etc.

How the access token is being used is = just like a cookie. The AS gives a string to the client and the client must= pass the string back to the AS when it calls it,=C2=A0the AS may then give= a new string=C2=A0to the client for the next call. Works like a cookie. I = don't know why you think there are legal issues around this.=C2=A0

/Dick



3D==E1=90=A7

On Sun, Nov 22, 2020 at 11:40 PM Fa= bien Imbault <fabien.imbault@gmail.com> wrote:
Hi Dick,

In GNAP, the client = isn't managing state (unlike a web app), the entire point is that the l= ifecycle should be managed by the AS.=C2=A0

As in any state machine, there are states and transitio= ns. Here we're not passing state, merely expressing "please contin= ue". The client can be completely unaware of the underlying state.=C2= =A0
In effect= the client only has the ability to ask the server to generate the next tra= nsition.

So I= don't think you can compare that to cookies. It's a different beha= vior. BTW if it was the case it would lead to a whole new class of issues, = because there's an entire legal framework around cookies...=C2=A0
=

To avoid confusion with a sta= ndard access token, we have the "key" field. My proposal would be= to make it more explicitly (cf comment in issue 67).

Fabien=C2=A0


Le lun. 23 nov. = 2020 =C3=A0 02:06, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit=C2=A0:
When I look at how GNAP is using access tokens f= or continuation requests, and the pull request=C2=A0#129

Those "access = tokens" look a lot more like cookies (managing state) than how access = tokens are usually used (representing authorization). See table below.

If there is a real requirement for passing state back = and forth between a server (the AS in this case) and the client when making= API calls, then I suggest that is out of scope for GNAP as I see it being = a general=C2=A0purpose mechanism for any API.

/Dic= k


cookies
- issued by server being a= ccessed
- are not presented to other servers
- issued after first acc= ess
- may be different for different URLs
- may be updated on each ac= cess
- represents the context of a session (state)

access toke= ns
- issued by an independent service (AS)
- may be used at any U= RL at the RS
- new ones issued by AS as needed
- represents authoriza= tion granted to a client at an RS
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
<= /blockquote>

--000000000000a77db605b557e589--