Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892B13A0C4A for ; Wed, 8 Jul 2020 07:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvnM-QzDY4j8 for ; Wed, 8 Jul 2020 07:32:47 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C1F3A0C44 for ; Wed, 8 Jul 2020 07:32:46 -0700 (PDT) Received: from [192.168.1.7] (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 068EWia7020209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jul 2020 10:32:45 -0400 From: Justin Richer Message-Id: <2D3EEF56-BD86-42DF-82D2-7595E19C5350@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_41DD2BAF-E9DB-456A-890B-BC401539B9BC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 8 Jul 2020 10:32:44 -0400 In-Reply-To: Cc: txauth@ietf.org To: Tobias Looker References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <6846D2F0-5096-404B-A529-676146392F45@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 14:32:52 -0000 --Apple-Mail=_41DD2BAF-E9DB-456A-890B-BC401539B9BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think there are two interesting layers here:=20 - Information that the client needs to know. This is what started the = thread, the whole =E2=80=9Chow and where am I allowed to use this = token=E2=80=9D question. This is stuff that would be put alongside the = token in the response from the AS, not inside the token. - Information that the RS needs to know. This is I think where the = attenuation, proofing, and the actual rights associated with the token = would go. This is stuff that would either be in the token itself or in a = return from an introspection style call. Both of these fit into the =E2=80=9Cconsistent token model=E2=80=9D part = of GNAP, but different aspects need to be communicated in different = ways.=20 =E2=80=94 Justin > On Jul 7, 2020, at 8:01 PM, Tobias Looker = wrote: >=20 > I've also been thinking about the parallels between ZCAP's and = OAuth2.0 access tokens. To me a ZCAP is a less opaque, semantically = richer capability format, whereas an access_token is traditionally much = simpler. The key here though is I still see an access_token as a form of = capability. It appears in general one of the trade offs we will be faced = with is either: >=20 > 1. Keeping the capability received from a GNAP flow (e.g an = access_token) opaque to the client and externalizing any greater = information about how to use the capability (such as in your proposal in = the first email of this thread). > 2. Internalizing information about the capabilities utility and any = greater context about it which means the capability is no longer opaque. >=20 > With that aside, the notable features in general I would like GNAP to = consider from ZCAP's, are the following. >=20 > - Delegatable capabilities (bonus if this mechanism includes the = ability to attenuate during delegation) - Consider the example where a = client or RP (RP1) receives some form of access_token (capability) from = an AS and would like to delegate this to another RP (RP2) so they can = access the same resources. If including attenuation this would mean that = during this delegation (RP1->RP2), RP1 could narrow the scope of the = original access it received so that RP2 only gets a subset of the = original scope. > - Bound capabilities - Similar in some ways to dPop, essentially = establishing the ability to bind an access_token (capability) to the = party that should be able to use it (invoker). I see this as a must have = in order to be able to do attenuated delegation as described above. >=20 > Thanks, > =09 > Tobias Looker > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > = = = > This communication, including any attachments, is confidential. If you = are not the intended recipient, you should not read it - please contact = me immediately, destroy it, and do not copy or use any part of this = communication or disclose anything about it. Thank you. Please note that = this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >=20 >=20 > On Wed, Jul 8, 2020 at 8:39 AM Justin Richer > wrote: > I=E2=80=99ve been thinking more about these use cases, and it might = help us to think of GNAP=E2=80=99s access tokens as capabilities in the = computer security sense =E2=80=94 but more specifically, capabilities = that are delivered with their own context for use. In that way, an = otherwise naive client can be handed an access token and simply know = exactly what to do with it. This context would be delivered alongside = the token, so the token material itself remains opaque to the client. >=20 > I wanted to bring up a W3C spec for a capabilities model based on = linked data: >=20 > https://w3c-ccg.github.io/zcap-ld/ = >=20 > Building a fully featured capabilities context is difficult, at the = very least. And unfortunately, I don=E2=80=99t think this spec actually = gives us any viable solutions to work with. In particular the = =E2=80=9Cactions=E2=80=9D section is effectively blank, offloading the = work to an external JSONLD process (side note, this is one of the = problems I have with specs based on JSONLD, they externalize the = important parts into local contexts and break interoperability =E2=80=94 = but I digress). But at least it=E2=80=99s another way of looking at the = problem space that might be outside the familiar zone of many of the = OAuth world. >=20 > =E2=80=94 Justin >=20 >> On Jun 26, 2020, at 9:23 AM, Justin Richer > wrote: >>=20 >> On Jun 25, 2020, at 9:07 PM, Tobias Looker = > wrote: >>>=20 >>> I find this feature interesting and think it could be an important = pattern going forward to enable an AS to be able to describe the utility = of a token to the client, however as already pointed out in the thread I = think there is some potential hidden complexity that would need to be = ironed out such that it does not make the simple things complicated. >>>=20 >>> Justin, do you see this feature as something the client has to = explicitly request, i.e "please give me access and instructions on how = to use my access" or rather that the AS would just return this = information in conjunction with the access token if it had it available? >>>=20 >>=20 >> This is something that I=E2=80=99d brought up as a possibility on the = previous thread =E2=80=94 something like a flag the client would set. = This would be especially important if the AS wants to return multiple = access tokens but the client requested 1, or the client requested N and = the AS wants to return M in response. Basically any time there=E2=80=99s = a mismatch, that=E2=80=99s extra complexity on the client that I really = don=E2=80=99t think we want to be universal. A flag to turn that kind of = direction and splitting on would be a potential start. But there are = potential snags here too, and it comes down to how you manage the = defaults... >>=20 >>> > This is just the start, too. Things get even more complex if the = client can ask for multiple different kinds of resources at once. What = if the AS decides that the client needs a hyper-focused directed token = for one part of the API, but can use a general token for other stuff? = Can it signal that to the client? And if it can, does that mean that all = clients need to be prepared for that kind of thing? >>>=20 >>> 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? >>=20 >> That=E2=80=99s the real trick, if you ask me. It has to be :safe: for = a client to ignore this information. Which means the AS can=E2=80=99t = rely on the client =E2=80=9Cdoing the right thing=E2=80=9D with the = information in the =E2=80=9Ctoken directions=E2=80=9D portion of the = response. Even setting aside the advanced and related =E2=80=9Csplit = tokens=E2=80=9D idea above, we need to make sure that an AS/RS setup is = built such that if the AS tells a client =E2=80=9Conly do X with your = token=E2=80=9D and the client does =E2=80=9CY=E2=80=9D, then there are = other protections and practices in place to prevent things from going = haywire if the client does =E2=80=9CY=E2=80=9D either by accident or = through ignorance.=20 >>=20 >> If OAuth 2 has taught us anything, it=E2=80=99s that client = applications are going to be the laziest participants in the security = model. And that makes sense, really =E2=80=94 security isn=E2=80=99t = what the client apps are trying to do, they=E2=80=99re trying to use the = RS to do something. So we need to make sure that whatever system we = design will fail on the safe side as much as possible, and keep things = simple for the client. >>=20 >>>=20 >>> > here are some worked out samples of this: >>> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token = >>> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ = >>> Peace ..tom >>>=20 >>> As one of the authors of those mentioned drafts, I am interested in = discussing that, but perhaps on a seperate thread? As at least the bound = assertion spec is primarily concerned with binding mechanisms for the = artifacts produced from an authorization flow (specifically identity = claims), whereas I think directed access tokens is just more generally = talking about whether GNAP should support an AS conveying how to use an = access_token it produces during a flow with a client. >>>=20 >>=20 >> I think that these are separate issues as well. >>=20 >> =E2=80=94 Justin >>=20 >>> Thanks, >>> =09 >>> Tobias Looker >>> Mattr >>> +64 (0) 27 378 0461 >>> tobias.looker@mattr.global >>> = = = >>> This communication, including any attachments, is confidential. If = you are not the intended recipient, you should not read it - please = contact me immediately, destroy it, and do not copy or use any part of = this communication or disclose anything about it. Thank you. Please note = that this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >>>=20 >>>=20 >>> On Wed, Jun 24, 2020 at 10:14 PM Denis > wrote: >>> Justin, I fear we are still far away from an agreement about what = this BoF should do. >>>=20 >>> Tom Jones is saying " I am getting tired of the whack-a-mole = approach ..." >>>=20 >>> I don't agree with you when you write: "I think it=E2=80=99s going = to be overwhelmingly common that a given RS is going to trust exactly = one AS=20 >>> that it knows about ahead of time". Such an architecture would have = exactly the same limitations as OAuth 2.0. and would not be scalable. >>>=20 >>> Before we start, we should have a clear view of the whole picture = rather than starting from one scenario and expanding it in many = different directions. >>> For building an architecture, a pre-requirement is to define ALL the = trust relationships. I don't believe that we have an agreement at this = time on what=20 >>> these trust relationships are.=20 >>>=20 >>> You are also using the following wording: "methods for the AS and RS = to communicate what the token=E2=80=99s good for".=20 >>> With such a paradigm, it would be impossible to protect the user's = privacy.=20 >>>=20 >>> A key question is : Will GNAP take care of the user's privacy or = will GNAP prevent to take care of the user's privacy ? >>>=20 >>> About "the ability for the client to get several access tokens to = get different resources from one request" is indeed a complex case. >>>=20 >>> No one (including ASs) is able to predict in advance which access = tokens will be needed, since they depend upon the kind of operation(s)=20= >>> the client will be willing to perform. For privacy reasons, ASs = should be kept ignorant of all the operations that a client is going to = perform=20 >>> on one or more resource servers. I believe that every effort should = be made to avoid the AS to be in a position to be able to trace the = operations=20 >>> performed by its clients on various RSs. >>>=20 >>> To handle the complex case you envision, the full workflow of = operations needs to be considered with a detailed focus on the time=20 >>> at which the user's consent and choice happens (consent and choice = is the first privacy principle from ISO 29100). >>>=20 >>> First of all, an access token could be targeted to a service rather = than to a server. This would already solve many cases. >>>=20 >>> When a RS needs to call another RS (which does not support the same = service) then the client should be informed by the first RS. >>> His "consent and choice" should then be obtained by the first RS = and, when the user agrees, the client should then ask an access token=20 >>> to one of the ASs trusted by the second RS in order to perform the = subsequent operation. =20 >>>=20 >>> Denis >>>=20 >>> PS. In an email sent on June 23 you wrote: " I think an on-device = AS is an important use case". I am sorry, but I don't understand. >>> However, I do understand what "a server-based AS" is. >>>=20 >>>=20 >>>> Denis, thanks for the great comments. I think that your trust model = is pretty different from what I=E2=80=99d laid out initially, and while = it=E2=80=99s an interesting and important one, it is not what I meant by = =E2=80=9Cmultiple access tokens=E2=80=9D in my discussion below. I think = that might be the cause of some disconnect here, but that doesn=E2=80=99t = mean it=E2=80=99s out of reach for what the WG is after. >>>>=20 >>>> When I refer to multiple access tokens, and what the charter calls = out as multiple access tokens, is the ability for the client to get = several access tokens to get different resources from one request. I = personally see this as an optimization of a specific set of use cases, = some of which I discussed in my original email. There are others, I=E2=80=99= m sure, but all the ones I=E2=80=99ve seen are around the client needing = to get several different kinds of access through an AS.=20 >>>>=20 >>>> I think it=E2=80=99s going to be overwhelmingly common that a given = RS is going to trust exactly one AS that it knows about ahead of time. = But for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we = should have a model that can accommodate that as well. That=E2=80=99s = why the charter calls out methods for the AS and RS to communicate what = the token=E2=80=99s good for. I think the basis of those methods is = going to start with a common token model, and likely incorporate into = things like token formats and introspection-style token APIs.=20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Jun 22, 2020, at 3:55 AM, Denis > wrote: >>>>>=20 >>>>> Hello Justin, >>>>>=20 >>>>> A few comments between the lines. >>>>>=20 >>>>>> One of the most important aspects to GNAP is going to be an = ability to address things that OAuth 2 can=E2=80=99t, or at least = can=E2=80=99t do without significant gymnastics. So with that, I wanted = to bring back a use case discussion that originally came up while we = were talking about the possibility of multiple access tokens, a few = months back. I don=E2=80=99t know if this concept has a regular term, so = I=E2=80=99m going to call it =E2=80=9Cdirected access tokens=E2=80=9D = until we come up with something better =E2=80=94 assuming we decide this = is worthwhile.=20 >>>>> I don't understand what may mean "directed access tokens=E2=80=9D = but I understand what means "multiple access tokens".=20 >>>>> When speaking of "multiple access tokens", these access tokens may = come from one or more ASs. >>>>>=20 >>>>>> In OAuth, the client=E2=80=99s supposed to always know where to = send its access token, and that knowledge is completely outside the = protocol. This makes a lot of sense for many (if not most) deployments, = as OAuth is really there to enable the API access that the client = already knows about. >>>>>>=20 >>>>>> But we=E2=80=99re now in a world where a client could be talking = to a generic API that could be deployed at a number of different places, = or a cloud deployment that the AS wants to be able to dispatch the = client to.=20 >>>>> As soon the AS is placed (again) at the centre of the model, the = AS will have the ability to act as "Big Brother". >>>>> OAuth 2.0 has not taken care of privacy issues. On the contrary, = GNAP should take care of them. >>>>>=20 >>>>>> In order to do this, the AS needs to be able to communicate to = the client not only the token information (and any related key and = presentation information), but also a set of directions about what that = specific token is good for. This needs to be information outside the = token itself, since I believe we want to keep OAuth 2=E2=80=99s feature = of having the token be opaque to the client. Note: while we could map = all of these to different resource requests (in XYZ parlance) or scopes = (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t = enough to tell the client what to do with the token if it doesn=E2=80=99t = know already.=20 >>>>>>=20 >>>>>> I know of two use cases already in the wild, where people are = addressing things using a mix of existing standards and some proprietary = extensions to address things within their silos. I=E2=80=99ll try to = summarize here, but I know the folks I=E2=80=99ve been talking to about = this are also on the list so hopefully they can chime in with more = detail or any corrections for something I=E2=80=99ve missed.=20 >>>>>>=20 >>>>>> (1) The client knows what resource it=E2=80=99s calling, but it = doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a = single security domain controlled by the AS,=20 >>>>> Speaking of "multiple access tokens" is in contradiction with = single security domain "controlled" by an AS.=20 >>>>> A user may need to demonstrate some of his identity attributes = granted e.g. by his bank but may also=20 >>>>> need to demonstrate one or more diplomas granted by one or more = universities. The bank cannot be=20 >>>>> the "primary issuer" of a university diploma. It should not be = either a "secondary issuer", because=20 >>>>> the bank does not "need to know" what are the diplomas of the = user. >>>>>=20 >>>>>> but the AS needs to decide at runtime which specific instance of = the API to direct the client to. Since things are closely tied together, = the client just needs to effectively known an identifier for the RS, and = this is currently implemented as a URI. Once the client has that = identifier, it knows how to dispatch that token to that instance of the = RS. >>>>> There is no good reason why the AS should be involved in that = step.=20 >>>>> OAuth 2.0 is/was implicitly mandating a strong relationship = between ASs and RSs which makes it non scalable. >>>>> GNAP should be based on a simple trust relationship : a given RS = trusts some ASs for access tokens that contains some types of = attributes. >>>>> An AS should not need to know in advance (or even at the time of = an access token request) the RSs that are trusting it. >>>>>=20 >>>>> A client could first talk to a "global service provider" which has = the knowledge of the different RSs affiliated to it.=20 >>>>>=20 >>>>>> (2) The client knows what kind of thing it=E2=80=99s looking for, = but doesn=E2=80=99t know who to ask it from.=20 >>>>> Once again, the client could first talk to a "global service = provider" which has the knowledge of the different RSs affiliated to it.=20= >>>>>=20 >>>>>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by = the AS, and the AS needs to dispatch to different resources depending on = which user logged in (and possibly what the user consented to). To make = things more concrete, the client needs to get driver=E2=80=99s license = information, but doesn=E2=80=99t know ahead of time which of the many = state/provincial bureaus to call to get that information because it = doesn=E2=80=99t know yet who the user is.=20 >>>>> When a user has a driving license, he knows its issuer. The user = can then provide some hint to the client. >>>>>=20 >>>>>> The AS will know who the user is once they log in and approve = things, and so it can direct the client to call the correct RS. Since = this is a relatively simple API with a pre-negotiated cross-domain = trust, the AS returns a URL that the client presents the token at.=20 >>>>> A single AS should not be aware of all the attributes a user has.=20= >>>>>=20 >>>>>>=20 >>>>>> As far as I know, in both of these cases, the token is only good = for that API and not others =E2=80=94 but more on that later. >>>>>>=20 >>>>>> A simple thing to do is just give back a URL with the access = token, which tells the client where to go.=20 >>>>>>=20 >>>>>> { >>>>>> =E2=80=9Caccess_token=E2=80=9D: { >>>>>> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80= =9D, >>>>>> =E2=80=9Cresource_uri=E2=80=9D: = =E2=80=9Chttps://example/foo " >>>>>> } >>>>>> } >>>>>>=20 >>>>>> This is good for some kinds of APIs, but it=E2=80=99s limiting = because not all APIs dispatch based on the URL. An AS might want to = divvy up access tokens to an API that=E2=80=99s keyed on headers, or = verbs, or any number of things. And it doesn=E2=80=99t tell us = immediately what to do about non-exact URL matches. Can the client add = query parameters and still use the token? What about path segments? I = like that this simple approach addresses some common deployments that we = already see today (see above), it=E2=80=99s not universal. Do we want or = need a universal description language for directing where tokens go? >>>>>>=20 >>>>>> This also opens up a whole new set of security questions. If the = AS can now direct the client where to use the token, could a rogue AS = convince a legit client to use a stolen token at the wrong RS? And what = if the client ignores the directions from the AS entirely? Could this = open up new avenues of attack? >>>>>>=20 >>>>>> This is just the start, too. Things get even more complex if the = client can ask for multiple different kinds of resources at once. What = if the AS decides that the client needs a hyper-focused directed token = for one part of the API, but can use a general token for other stuff? = Can it signal that to the client? And if it can, does that mean that all = clients need to be prepared for that kind of thing? >>>>>>=20 >>>>>> I firmly believe that whatever we build in GNAP, we need to = optimize for the overwhelmingly common use case of a client getting a = single access token to call APIs that it already knows about. Anything = we add on top of that really can=E2=80=99t get in the way of this, = because if it does, there=E2=80=99s very small chance that people will = try to use this for everyday things. Keep the simple things simple, and = the complex things possible, after all. >>>>>>=20 >>>>>> I=E2=80=99m really looking forward to hearing what the community = thinks about these use cases, and hopefully the people I=E2=80=99ve = chatted with offline about this can join the conversation and provide = more light than I was able to. >>>>> The two use cases which are considered above are: >>>>>=20 >>>>> (1) The client knows what resource it=E2=80=99s calling, but it = doesn=E2=80=99t know where it=E2=80=99s hosted. >>>>> (2) The client knows what kind of thing it=E2=80=99s looking for, = but doesn=E2=80=99t know who to ask it from.=20 >>>>>=20 >>>>> That does not mean in any way that these two use cases should be = solved by placing the AS at the centre of the solution. >>>>>=20 >>>>> Denis >>>>>=20 >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>> This communication, including any attachments, is confidential. If = you are not the intended recipient, you should not read it - please = contact me immediately, destroy it, and do not copy or use any part of = this communication or disclose anything about it. Thank you. Please note = that this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > This communication, including any attachments, is confidential. If you = are not the intended recipient, you should not read it - please contact = me immediately, destroy it, and do not copy or use any part of this = communication or disclose anything about it. Thank you. Please note that = this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. --Apple-Mail=_41DD2BAF-E9DB-456A-890B-BC401539B9BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think there are two interesting layers here: 

 - Information that the client = needs to know. This is what started the thread, the whole =E2=80=9Chow = and where am I allowed to use this token=E2=80=9D question. This is = stuff that would be put alongside the token in the response from the AS, = not inside the token.

 - Information that the RS needs to know. This is I = think where the attenuation, proofing, and the actual rights associated = with the token would go. This is stuff that would either be in the token = itself or in a  return from an introspection style call.

Both of these fit into = the =E2=80=9Cconsistent token model=E2=80=9D part of GNAP, but different = aspects need to be communicated in different ways. 

 =E2=80=94 = Justin

On Jul 7, 2020, at 8:01 PM, Tobias Looker = <tobias.looker@mattr.global> wrote:

I've also been thinking about the = parallels between ZCAP's and OAuth2.0 access tokens. To me a ZCAP is a = less opaque, semantically richer capability format, whereas an = access_token is traditionally much simpler. The key here though is I = still see an access_token as a form of capability. It appears in general = one of the trade offs we will be faced with is either:

1. Keeping the capability = received from a GNAP flow (e.g an access_token) opaque to the = client and externalizing any greater information about how to use the = capability (such as in your proposal in the first email of this = thread).
2. Internalizing information about the = capabilities utility and any greater context about it which means the = capability is no longer opaque.

With that aside, the notable features = in general I would like GNAP to consider from ZCAP's, are the = following.

- = Delegatable capabilities (bonus if this mechanism includes the ability = to attenuate during delegation) - Consider the example where a client or = RP (RP1) receives some form of access_token (capability) from an AS = and would like to delegate this to another RP (RP2) so they can access = the same resources. If including attenuation this would mean = that during this delegation (RP1->RP2), RP1 could narrow the scope of = the original access it received so that RP2 only gets a subset of = the original scope.
- Bound capabilities - Similar = in some ways to dPop, essentially establishing the ability to bind an = access_token (capability) to the party that should be able to use it = (invoker). I see this as a must have in order to be able to do = attenuated delegation as described above.

Thanks,
3D"Mattr 
Tobias Looker
Mattr
+64 = (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D"Mattr3D"Mattr3D"Mattr

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


On Wed, Jul = 8, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99ve been thinking more about these use = cases, and it might help us to think of GNAP=E2=80=99s access tokens as = capabilities in the computer security sense =E2=80=94 but more = specifically, capabilities that are delivered with their own context for = use. In that way, an otherwise naive client can be handed an access = token and simply know exactly what to do with it. This context would be = delivered alongside the token, so the token material itself remains = opaque to the client.

I wanted to bring up a W3C spec for a capabilities model = based on linked data:

https://w3c-ccg.github.io/zcap-ld/
Building a fully featured capabilities = context is difficult, at the very least. And unfortunately, I don=E2=80=99= t think this spec actually gives us any viable solutions to work with. = In particular the =E2=80=9Cactions=E2=80=9D section is effectively = blank, offloading the work to an external JSONLD process (side note, = this is one of the problems I have with specs based on JSONLD, they = externalize the important parts into local contexts and break = interoperability =E2=80=94 but I digress). But at least it=E2=80=99s = another way of looking at the problem space that might be outside the = familiar zone of many of the OAuth world.

 =E2=80=94 Justin

On Jun 26, 2020, at 9:23 AM, Justin Richer <jricher@mit.edu> wrote:

On Jun 25, 2020, = at 9:07 PM, Tobias Looker <tobias.looker@mattr.global> = wrote:

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

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


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

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

Would a potential default be that if a = client did for any reason not support processing the additional = information returned with the access_token, just to ignore it? I think = in the spirit of keeping the simple things simple, this potentially = makes sense?

That=E2=80=99s the real trick, if you = ask me. It has to be :safe: for a client to ignore this information. = Which means the AS can=E2=80=99t rely on the client =E2=80=9Cdoing the = right thing=E2=80=9D with the information in the =E2=80=9Ctoken = directions=E2=80=9D portion of the response. Even setting aside the = advanced and related =E2=80=9Csplit tokens=E2=80=9D idea above, we need = to make sure that an AS/RS setup is built such that if the AS tells a = client =E2=80=9Conly do X with your token=E2=80=9D and the client does = =E2=80=9CY=E2=80=9D, then there are other protections and practices in = place to prevent things from going haywire if the client does =E2=80=9CY=E2= =80=9D either by accident or through ignorance. 

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


> here are some worked out samples of this:
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
https://mattrglobal.github.io/oidc-client-bound-assertions-spec= /
Peace ..tom

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


I think that these are separate issues = as well.

 =E2=80=94 Justin

Thanks,
3D"Mattr 
Tobias Looker
Mattr
+64 = (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D"Mattr3D"Mattr3D"Mattr

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


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

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

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

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

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

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

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

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

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

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

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

Denis

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


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

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

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

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

Hello Justin,

A few comments between the = lines.

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

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

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

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

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

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

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

Speaking of "multiple access tokens" is in = contradiction with single security domain "controlled" by an AS. 
A user may need to demonstrate = some of his identity attributes granted e.g. by his bank but may = also 
need to demonstrate one = or more diplomas granted by one or more universities. The bank cannot = be 
the "primary issuer" of a = university diploma. It should not be either a "secondary issuer", = because 
the bank does not = "need to know" what are = the diplomas of the user.

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

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

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

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

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

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

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

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

 A single AS should not be aware of = all the attributes a user has. 


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

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

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

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

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

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

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

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

The two use cases which are considered = above are:

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

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

Denis


 =E2=80=94 Justin


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


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

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

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


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

= --Apple-Mail=_41DD2BAF-E9DB-456A-890B-BC401539B9BC--