Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE01A3A080F for ; Fri, 26 Jun 2020 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0tFShVzzuSj for ; Fri, 26 Jun 2020 08:17:47 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CBB3A080A for ; Fri, 26 Jun 2020 08:17:47 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id k6so4470853oij.11 for ; Fri, 26 Jun 2020 08:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iUR4w0phaaHtQUpRrOYnNTpXA03Veg3rKaADOjFVh54=; b=LYzVvIifKsisy7IWSqfs4CnVL+uObgmOa8G+9XS/mbgEi+iXz9++kNI6wJC+V8lATq XMLSy2qJp9D0j7GHm45jPX4loKKfBJypzMb/dOZ2OuiHlYFplMG/m69AK9mr0AVkF954 F1HU5fKqMT+y916v/Kw0ELlX5/EA8fZH8IQSn2zzkzRW9qFvfA4lEMlNIUGX3xvgvD+q FAiqM8r5R2ETuGP1rD6eT+5WkO5L9M53Q2Lq69Hblg1kFIsCKmajpDlYn5KlQ0lRV96g EZdo+jOSXP0ukKuA8v6Y/cZLo4CksKHWp4mtqqLcXGGpnqTalQhsJPfcdRVStXmo7HMT tysA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iUR4w0phaaHtQUpRrOYnNTpXA03Veg3rKaADOjFVh54=; b=XlTsMixZvkSp1fi8nNC7KgoseF9ibu5lgLNnuq4L1RwAYetB7uF5B/pVdqO39+KebC NCq2ZEG2Rhpi6meS4447O7ho0HrSOUbbkrlooNdl+6Z6ZtC1wYqykzz1AncxNQeQQ43S IR/VukfexgH+hPy+tifnSWSAknpR845Hwi2fiMbIdeCSTkWcYQG/q5jdPxPSHUB073Od Br+3Ck+o8gvvB+jhtBlwIMkD5425NrpwiTxTMkC4JHjEzUjqmvmMAGCPA1xAdAb7zVdg AgFsIumxIu1fpsJbNn0cecirj7YfS9/zuWtJfiyUivSDUxyeLgwbFcqTm79IOuP5Z1Nk N6Gw== X-Gm-Message-State: AOAM5319nYQYTsiOyXgzEZNfci8qGguOtfDL2EINjNDC+nQSkdCQEvW6 DLnhfYgZ/cGzfywPrwBJqYb83m9BLGhRytU5GLg= X-Google-Smtp-Source: ABdhPJwM6M4KBhja+8M3J8yL7l5nTYinKLRXyZgguTdRgSzJBF1k63jfdoDsxw3fD81khNbzHmLa45eBO2eixFkOENM= X-Received: by 2002:aca:554c:: with SMTP id j73mr2912230oib.172.1593184666537; Fri, 26 Jun 2020 08:17:46 -0700 (PDT) MIME-Version: 1.0 References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> In-Reply-To: <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> From: Tom Jones Date: Fri, 26 Jun 2020 08:17:34 -0700 Message-ID: To: Justin Richer Cc: Tobias Looker , Denis , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000001c580005a8fe36b2" Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 15:17:51 -0000 --0000000000001c580005a8fe36b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While there are multiple reasons for bound tokens, each with their own needs, I strongly encourage an effort to create a single broad spec that could address the common security issues. Tobias, this is the general idea you were pushing on application level networking. As a general rule, I believe that the current effort to base security on channel binding has already been extended beyond its capabilities. (That is the concept that the HTTPS key is used as the security for the messages.) So, can't we focus on the problem of identifying the participants to an extended set of interchanges. This would formalize the earlier statements that the as and rs most likely have an ongoing security context on which to build subsequent interchanges. Peace ..tom On Fri, Jun 26, 2020 at 6:23 AM Justin Richer wrote: > On Jun 25, 2020, at 9:07 PM, Tobias Looker > wrote: > > > I find this feature interesting and think it could be an important patter= n > going forward to enable an AS to be able to describe the utility of a tok= en > to the client, however as already pointed out in the thread I think there > is some potential hidden complexity that would need to be ironed out such > that it does not make the simple things complicated. > > Justin, do you see this feature as something the client has to explicitly > request, i.e "please give me access and instructions on how to use my > access" or rather that the AS would just return this information in > conjunction with the access token if it had it available? > > > This is something that I=E2=80=99d brought up as a possibility on the pre= vious > thread =E2=80=94 something like a flag the client would set. This would b= e > especially important if the AS wants to return multiple access tokens but > the client requested 1, or the client requested N and the AS wants to > return M in response. Basically any time there=E2=80=99s a mismatch, that= =E2=80=99s extra > complexity on the client that I really don=E2=80=99t think we want to be = universal. > A flag to turn that kind of direction and splitting on would be a potenti= al > start. But there are potential snags here too, and it comes down to how y= ou > manage the defaults... > > > This is just the start, too. Things get even more complex if the client > can ask for multiple different kinds of resources at once. What if the AS > decides that the client needs a hyper-focused directed token for one part > of the API, but can use a general token for other stuff? Can it signal th= at > to the client? And if it can, does that mean that all clients need to be > prepared for that kind of thing? > > Would a potential default be that if a client did for any reason not > support processing the additional information returned with the > access_token, just to ignore it? I think in the spirit of keeping the > simple things simple, this potentially makes sense? > > > That=E2=80=99s the real trick, if you ask me. It has to be :safe: for a c= lient to > ignore this information. Which means the AS can=E2=80=99t rely on the cli= ent =E2=80=9Cdoing > the right thing=E2=80=9D with the information in the =E2=80=9Ctoken direc= tions=E2=80=9D portion of > the response. Even setting aside the advanced and related =E2=80=9Csplit = tokens=E2=80=9D > idea above, we need to make sure that an AS/RS setup is built such that i= f > the AS tells a client =E2=80=9Conly do X with your token=E2=80=9D and the= client does =E2=80=9CY=E2=80=9D, > then there are other protections and practices in place to prevent things > from going haywire if the client does =E2=80=9CY=E2=80=9D either by accid= ent or through > ignorance. > > If OAuth 2 has taught us anything, it=E2=80=99s that client applications = are going > to be the laziest participants in the security model. And that makes sens= e, > really =E2=80=94 security isn=E2=80=99t what the client apps are trying t= o do, they=E2=80=99re > trying to use the RS to do something. So we need to make sure that whatev= er > system we design will fail on the safe side as much as possible, and keep > things simple for the client. > > > > here are some worked out samples of this: > https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token > https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ > Peace ..tom > > As one of the authors of those mentioned drafts, I am interested in > discussing that, but perhaps on a seperate thread? As at least the bound > assertion spec is primarily concerned with binding mechanisms for the > artifacts produced from an authorization flow (specifically identity > claims), whereas I think directed access tokens is just more generally > talking about whether GNAP should support an AS conveying how to use an > access_token it produces during a flow with a client. > > > I think that these are separate issues as well. > > =E2=80=94 Justin > > Thanks, > [image: Mattr website] > *Tobias Looker* > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > [image: Mattr website] [image: Mattr on LinkedIn] > [image: Mattr on Twitter] > [image: Mattr on Github] > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > On Wed, Jun 24, 2020 at 10:14 PM Denis wrote: > >> Justin, I fear we are still far away from an agreement about what this >> BoF should do. >> >> Tom Jones is saying " I am getting tired of the whack-a-mole approach ..= ." >> >> I don't agree with you when you write: "I think it=E2=80=99s going to be >> overwhelmingly common that a given RS is going to trust exactly one AS >> that it knows about ahead of time". Such an architecture would have >> exactly the same limitations as OAuth 2.0. and would not be scalable. >> >> Before we start, we should have a clear view of the whole picture rather >> than starting from one scenario and expanding it in many different >> directions. >> For building an architecture, a pre-requirement is to define ALL the >> trust relationships. I don't believe that we have an agreement at this t= ime >> on what >> these trust relationships are. >> >> You are also using the following wording: "methods for the AS and RS to >> communicate what the token=E2=80=99s good for". >> With such a paradigm, it would be impossible to protect the user's >> privacy. >> >> A key question is : Will GNAP take care of the user's privacy or will >> GNAP *prevent *to take care of the user's privacy ? >> >> About "the ability for the client to get several access tokens to get >> different resources from one request" is indeed a complex case. >> >> No one (including ASs) is able to predict in advance which access tokens >> will be needed, since they depend upon the kind of operation(s) >> the client will be willing to perform. For privacy reasons, ASs should b= e >> kept ignorant of all the operations that a client is going to perform >> on one or more resource servers. I believe that every effort should be >> made to avoid the AS to be in a position to be able to trace the operati= ons >> performed by its clients on various RSs. >> >> To handle the complex case you envision, the full workflow of operations >> needs to be considered with a detailed focus on the time >> at which the user's *consent and choice* happens (*consent and choice* >> is the first privacy principle from ISO 29100). >> >> First of all, an access token could be targeted to a service rather than >> to a server. This would already solve many cases. >> >> When a RS needs to call another RS (which does not support the same >> service) then the client should be informed by the first RS. >> His "consent and choice" should then be obtained by the first RS and, >> when the user agrees, the client should then ask an access token >> to one of the ASs trusted by the second RS in order to perform the >> subsequent operation. >> >> Denis >> >> PS. In an email sent on June 23 you wrote: " I think an on-device AS is >> an important use case". I am sorry, but I don't understand. >> However, I do understand what "a server-based AS" is. >> >> >> Denis, thanks for the great comments. I think that your trust model is >> pretty different from what I=E2=80=99d laid out initially, and while it= =E2=80=99s an >> interesting and important one, it is not what I meant by =E2=80=9Cmultip= le access >> tokens=E2=80=9D in my discussion below. I think that might be the cause = of some >> disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of reach= for what the WG is >> after. >> >> When I refer to multiple access tokens, and what the charter calls out a= s >> multiple access tokens, is the ability for the client to get several acc= ess >> tokens to get different resources from one request. I personally see thi= s >> as an optimization of a specific set of use cases, some of which I >> discussed in my original email. There are others, I=E2=80=99m sure, but = all the >> ones I=E2=80=99ve seen are around the client needing to get several diff= erent kinds >> of access through an AS. >> >> I think it=E2=80=99s going to be overwhelmingly common that a given RS i= s going >> to trust exactly one AS that it knows about ahead of time. But for RS=E2= =80=99s >> that can trust multiple AS=E2=80=99s, then we should have a model that c= an >> accommodate that as well. That=E2=80=99s why the charter calls out metho= ds for the >> AS and RS to communicate what the token=E2=80=99s good for. I think the = basis of >> those methods is going to start with a common token model, and likely >> incorporate into things like token formats and introspection-style token >> APIs. >> >> =E2=80=94 Justin >> >> On Jun 22, 2020, at 3:55 AM, Denis wrote: >> >> Hello Justin, >> >> A few comments between the lines. >> >> One of the most important aspects to GNAP is going to be an ability to >> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do = without significant >> gymnastics. So with that, I wanted to bring back a use case discussion t= hat >> originally came up while we were talking about the possibility of multip= le >> access tokens, a few months back. I don=E2=80=99t know if this concept h= as a >> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access t= okens=E2=80=9D until we >> come up with something better =E2=80=94 assuming we decide this is worth= while. >> >> I don't understand what may mean "directed access tokens=E2=80=9D but I >> understand what means "multiple access tokens". >> When speaking of "multiple access tokens", these access tokens may come >> from one or more ASs. >> >> In OAuth, the client=E2=80=99s supposed to always know where to send its= access >> token, and that knowledge is completely outside the protocol. This makes= a >> lot of sense for many (if not most) deployments, as OAuth is really ther= e >> to enable the API access that the client already knows about. >> >> But we=E2=80=99re now in a world where a client could be talking to a ge= neric API >> that could be deployed at a number of different places, or a cloud >> deployment that the AS wants to be able to dispatch the client to. >> >> As soon the AS is placed (again) at the centre of the model, the AS will >> have the ability to act as "Big Brother". >> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP >> should take care of them. >> >> In order to do this, the AS needs to be able to communicate to the clien= t >> not only the token information (and any related key and presentation >> information), but also a set of *directions* about what that specific >> token is good for. This needs to be information outside the token itself= , >> since I believe we want to keep OAuth 2=E2=80=99s feature of having the = token be >> opaque to the client. Note: while we could map all of these to different >> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlanc= e) >> on the request side, this isn=E2=80=99t enough to tell the client what t= o do with >> the token *if it doesn=E2=80=99t know already*. >> >> I know of two use cases already in the wild, where people are addressing >> things using a mix of existing standards and some proprietary extensions= to >> address things within their silos. I=E2=80=99ll try to summarize here, b= ut I know >> the folks I=E2=80=99ve been talking to about this are also on the list s= o hopefully >> they can chime in with more detail or any corrections for something I=E2= =80=99ve >> missed. >> >> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know >> where it=E2=80=99s hosted. Everything is in a single security domain con= trolled by >> the AS, >> >> Speaking of "multiple access tokens" is in contradiction with single >> security domain "controlled" by an AS. >> A user may need to demonstrate some of his identity attributes granted >> e.g. by his bank but may also >> need to demonstrate one or more diplomas granted by one or more >> universities. The bank cannot be >> the "primary issuer" of a university diploma. It should not be either a >> "secondary issuer", because >> the bank does not "*need to know"* what are the diplomas of the user. >> >> but the AS needs to decide at runtime which specific instance of the API >> to direct the client to. Since things are closely tied together, the cli= ent >> just needs to effectively known an identifier for the RS, and this is >> currently implemented as a URI. Once the client has that identifier, it >> knows how to dispatch that token to that instance of the RS. >> >> There is no good reason why the AS should be involved in that step. >> OAuth 2.0 is/was implicitly mandating a strong relationship between ASs >> and RSs which makes it non scalable. >> GNAP should be based on a simple trust relationship : a given RS trusts >> some ASs for access tokens that contains some types of attributes. >> An AS should not need to know in advance (or even at the time of an >> access token request) the RSs that are trusting it. >> >> A client could first talk to a "global service provider" which has the >> knowledge of the different RSs affiliated to it. >> >> (2) The client knows what kind of thing it=E2=80=99s looking for, but do= esn=E2=80=99t >> know who to ask it from. >> >> Once again, the client could first talk to a "global service provider" >> which has the knowledge of the different RSs affiliated to it. >> >> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, a= nd the AS needs >> to dispatch to different resources depending on which user logged in (an= d >> possibly what the user consented to). To make things more concrete, the >> client needs to get driver=E2=80=99s license information, but doesn=E2= =80=99t know ahead of >> time which of the many state/provincial bureaus to call to get that >> information because it doesn=E2=80=99t know yet who the user is. >> >> When a user has a driving license, he knows its issuer. The user can the= n >> provide some hint to the client. >> >> The AS will know who the user is once they log in and approve things, an= d >> so it can direct the client to call the correct RS. Since this is a >> relatively simple API with a pre-negotiated cross-domain trust, the AS >> returns a URL that the client presents the token at. >> >> A single AS should not be aware of all the attributes a user has. >> >> >> As far as I know, in both of these cases, the token is only good for tha= t >> API and not others =E2=80=94 but more on that later. >> >> A simple thing to do is just give back a URL with the access token, whic= h >> tells the client where to go. >> >> { >> =E2=80=9Caccess_token=E2=80=9D: { >> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D, >> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo" >> } >> } >> >> This is good for some kinds of APIs, but it=E2=80=99s limiting because n= ot all >> APIs dispatch based on the URL. An AS might want to divvy up access toke= ns >> to an API that=E2=80=99s keyed on headers, or verbs, or any number of th= ings. And >> it doesn=E2=80=99t tell us immediately what to do about non-exact URL ma= tches. Can >> the client add query parameters and still use the token? What about path >> segments? I like that this simple approach addresses some common >> deployments that we already see today (see above), it=E2=80=99s not univ= ersal. Do >> we want or need a universal description language for directing where tok= ens >> go? >> >> This also opens up a whole new set of security questions. If the AS can >> now direct the client where to use the token, could a rogue AS convince = a >> legit client to use a stolen token at the wrong RS? And what if the clie= nt >> ignores the directions from the AS entirely? Could this open up new aven= ues >> of attack? >> >> This is just the start, too. Things get even more complex if the client >> can ask for multiple different kinds of resources at once. What if the A= S >> decides that the client needs a hyper-focused directed token for one par= t >> of the API, but can use a general token for other stuff? Can it signal t= hat >> to the client? And if it can, does that mean that all clients need to be >> prepared for that kind of thing? >> >> I firmly believe that whatever we build in GNAP, we need to optimize for >> the overwhelmingly common use case of a client getting a single access >> token to call APIs that it already knows about. Anything we add on top o= f >> that really can=E2=80=99t get in the way of this, because if it does, th= ere=E2=80=99s very >> small chance that people will try to use this for everyday things. Keep = the >> simple things simple, and the complex things possible, after all. >> >> I=E2=80=99m really looking forward to hearing what the community thinks = about >> these use cases, and hopefully the people I=E2=80=99ve chatted with offl= ine about >> this can join the conversation and provide more light than I was able to= . >> >> The two use cases which are considered above are: >> >> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know >> where it=E2=80=99s hosted. >> (2) The client knows what kind of thing it=E2=80=99s looking for, but do= esn=E2=80=99t >> know who to ask it from. >> >> That does not mean in any way that these two use cases should be solved >> by placing the AS at the centre of the solution. >> >> Denis >> >> >> =E2=80=94 Justin >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > This communication, including any attachments, is confidential. If you ar= e not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communicatio= n or disclose anything about it. Thank you. Please note that this communica= tion does not designate an information system for the purposes of the Elect= ronic Transactions Act 2002. > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000001c580005a8fe36b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While there are multiple reasons for bound tokens, each wi= th their own needs, I strongly encourage an effort to create a single broad= spec that could address the common security issues. Tobias, this is the ge= neral idea you were pushing on application level networking. As a general r= ule, I believe=C2=A0that the current effort to base security on channel bin= ding has already been extended beyond=C2=A0its capabilities. (That is the c= oncept that the HTTPS key is used as the security for the messages.) So, ca= n't we focus on the problem of identifying the participants to an exten= ded set of interchanges. This would formalize the earlier statements that t= he as and rs most likely have an ongoing=C2=A0security context on which to = build subsequent interchanges.
Peace ..tom


On Fri, Jun 26, 2020 at 6:23 AM J= ustin Richer <jricher@mit.edu>= wrote:
On Jun 25, 2020, at 9:07 PM, Tobias Looke= r <tobia= s.looker@mattr.global> wrote:

=
I find this feature interesting and think it could be= an important=C2=A0pattern going=C2=A0forward to enable an AS to be able to= describe the utility of a token to the client, however as already pointed = out in the thread I think there is some potential hidden complexity that wo= uld need to be ironed out such that it does not make the simple things comp= licated.

Justin, do you see this feature as something th= e client has to explicitly request, i.e "please give me access and ins= tructions on how to use my access" or rather that the AS would just re= turn this information in conjunction with the access token if it had it ava= ilable?


Th= is is something that I=E2=80=99d brought up as a possibility on the previou= s thread =E2=80=94 something like a flag the client would set. This would b= e especially important if the AS wants to return multiple access tokens but= the client requested 1, or the client requested N and the AS wants to retu= rn M in response. Basically any time there=E2=80=99s a mismatch, that=E2=80= =99s extra complexity on the client that I really don=E2=80=99t think we wa= nt to be universal. A flag to turn that kind of direction and splitting on = would be a potential start. But there are potential snags here too, and it = comes down to how you manage the defaults...

> This is just the start, too. Things ge= t even more complex if the client can ask for multiple different kinds of r= esources at once. What if the AS decides that the client needs a hyper-focu= sed directed token for one part of the API, but can use a general token for= other stuff? Can it signal that to the client? And if it can, does that me= an that all clients need to be prepared for that kind of thing?
<= br>
Would a potential default be that if a client did for any rea= son not support processing the additional information returned with the acc= ess_token, just to ignore it? I think in the spirit of keeping the simple t= hings simple, this potentially makes sense?
<= div>
That=E2=80=99s the real trick, if you ask me. It has to = be :safe: for a client to ignore this information. Which means the AS can= =E2=80=99t rely on the client =E2=80=9Cdoing the right thing=E2=80=9D with = the information in the =E2=80=9Ctoken directions=E2=80=9D portion of the re= sponse. Even setting aside the advanced and related =E2=80=9Csplit tokens= =E2=80=9D idea above, we need to make sure that an AS/RS setup is built suc= h that if the AS tells a client =E2=80=9Conly do X with your token=E2=80=9D= and the client does =E2=80=9CY=E2=80=9D, then there are other protections = and practices in place to prevent things from going haywire if the client d= oes =E2=80=9CY=E2=80=9D either by accident or through ignorance.=C2=A0

If OAuth 2 has taught us anything, it=E2=80=99s that c= lient applications are going to be the laziest participants in the security= model. And that makes sense, really =E2=80=94 security isn=E2=80=99t what = the client apps are trying to do, they=E2=80=99re trying to use the RS to d= o something. So we need to make sure that whatever system we design will fa= il on the safe side as much as possible, and keep things simple for the cli= ent.


> here are some worked out samples of this:
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
Peace= ..tom

As one of the authors of those mentioned dr= afts, I am interested in discussing that, but perhaps on a seperate thread?= As at least=C2=A0the bound assertion spec is=C2=A0primarily=C2=A0concerned= with binding mechanisms for the artifacts produced from an authorization f= low (specifically identity claims), whereas I think directed access tokens = is just more generally talking about whether GNAP should support an AS conv= eying how to use an access_token it produces during a flow with a client.


I think that these are separate issues as well.
<= div>
=C2=A0=E2=80=94 Justin

Thanks,=
3D==C2=A0
Tobias Looker
Matt= r
+64 (0) 27 378 0461
= tobias.looker@mattr.global
3D"Mat=3D"Mattr=

This communication, including any att= achments, is confidential. If you are not the intended recipient, you shoul= d not read it - please contact me immediately, destroy it, and do not copy = or use any part of this communication or disclose anything about it. Thank = you. Please note that this communication does not designate an information = system for the purposes of the Electronic Transactions Act 2002.


On Wed, Jun 24, 2020 at 10:14 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it=E2=80=99s g= oing to be overwhelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time". Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what these trust relationships are.

You are also using the following wording: "methods for the AS and RS to communicate what the token=E2=80=99s good for".
With such a paradigm, it would be impossible to protect the user'= s privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user's privacy ?

About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice" should then be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation.=C2=A0

Denis

PS.=C2=A0 In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".= =C2=A0 I am sorry, but I don't understand.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 However, I do understand what &q= uot;a server-based AS" is.


=20 Denis, thanks for the great comments. I think that your trust model is pretty different from what I=E2=80=99d laid out initially, a= nd while it=E2=80=99s an interesting and important one, it is not what I meant by =E2=80=9Cmultiple access tokens=E2=80=9D in my discussion be= low. I think that might be the cause of some disconnect here, but that doesn=E2=80= =99t mean it=E2=80=99s out of reach for what the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I=E2=80=99m sure,= but all the ones I=E2=80=99ve seen are around the client needing to get several different kinds of access through an AS.=C2=A0

I think it=E2=80=99s going to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we should have a model that can accommodate th= at as well. That=E2=80=99s why the charter calls out methods for the AS= and RS to communicate what the token=E2=80=99s good for. I think the = basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most i= mportant aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do witho= ut significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99= t know if this concept has a regular term, so I=E2=80=99m g= oing to call it =E2=80=9Cdirected access tokens=E2=80=9D until= we come up with something better =E2=80=94 assuming we decide this i= s worthwhile.=C2=A0

I don't understand what may mean "directed access tokens=E2= =80=9D but I understand what means "multiple access tokens"= ;.=C2=A0
When speaking of "multiple access tokens", thes= e access tokens may come from one or more ASs.

In OAuth, the client=E2=80=99s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we=E2=80=99re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.=C2=A0

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".<= br> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of=C2=A0di= rections=C2=A0about what that specific token is good for. This needs to be information outside the token itself, since I=C2=A0believe we want to keep OAuth 2=E2=80=99s featur= e of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t enough to tell the client what to do with= the token=C2=A0if it doesn=E2=80=99t know a= lready.=C2=A0

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll try to summarize here, but I know the folk= s I=E2=80=99ve been talking to about this are also on the= list so hopefully they can chime in with more detail or any corrections for something I=E2=80=99ve missed.=C2= =A0

(1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s= hosted. Everything is in a single security domain controlled by the AS,=C2=A0

Speaking of "multiple access tokens" is in contradiction wi= th single security domain "controlled" by an AS.=C2=A0
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also=C2= =A0
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be=C2=A0<= /span>
the "primary issuer" of a university diploma. I= t should not be either a "secondary issuer", beca= use=C2=A0
the bank does not "need to know"= =C2=A0what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step.= =C2=A0
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which= has the knowledge of the different RSs affiliated to it.=C2=A0

(2) The client knows what kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t know who = to ask it from.=C2=A0

Once again, the client could first talk to a "global service provide= r" which has the knowledge of the different RSs affiliated to it.=C2=A0

There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80=99s license information, but doesn=E2=80= =99t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80= =99t know yet who the user is.=C2=A0

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.=C2=A0

=C2=A0A single AS should not be aware of all the attributes a user has.=C2=A0


As far as I know, in both of these cases, the token is only good for that API and not others =E2=80=94 but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go.=C2=A0

{
=E2=80= =9Caccess_token=E2=80=9D: {
=E2= =80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
=E2= =80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
}
}

This is good for some kinds of APIs, but it=E2=80=99s limiting because not all APIs dispatch bas= ed on the URL. An AS might want to divvy up access tokens to an API that=E2=80=99s keyed on headers, or verbs, or= any number of things. And it doesn=E2=80=99t tell us immedi= ately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80=99s not univers= al. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can=E2=80=99t get= in the way of this, because if it does, there=E2=80=99s ve= ry small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I=E2=80=99ve chatted with offline = about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what re= source it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s= hosted.
(2) The client knows what kind of thing it=E2=80=99s lo= oking for, but doesn=E2=80=99t know who to ask it from.= =C2=A0

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


=C2=A0=E2=80=94 Justin


--=C2= =A0
Txauth mail= ing list
Txauth@ietf= .org
https://www.ietf.org/mailman/listinfo/txauth


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

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.

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