Re: [Txauth] Use Case: Directed Tokens

Justin Richer <jricher@mit.edu> Tue, 23 June 2020 17:51 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978DF3A0880 for <txauth@ietfa.amsl.com>; Tue, 23 Jun 2020 10:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc5EpSTm56qk for <txauth@ietfa.amsl.com>; Tue, 23 Jun 2020 10:51:14 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB17F3A07A6 for <txauth@ietf.org>; Tue, 23 Jun 2020 10:51:13 -0700 (PDT)
Received: from [192.168.1.14] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05NHp9fT029860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jun 2020 13:51:09 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <4BA2CBE6-3A30-4425-A890-46E02AD699E2@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_868DAAB7-171C-4079-B4D2-7BBEBC7DB8BA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 23 Jun 2020 13:51:09 -0400
In-Reply-To: <CAK2Cwb6of95Wutio-jiv--VVU2iH07fo8m9oMOX-=+TdLboUNQ@mail.gmail.com>
Cc: Denis <denis.ietf@free.fr>, txauth@ietf.org
To: Tom Jones <thomasclinganjones@gmail.com>
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <CAK2Cwb6of95Wutio-jiv--VVU2iH07fo8m9oMOX-=+TdLboUNQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/j4cC4_fRTGMxBcPZN5vi817mEN8>
Subject: Re: [Txauth] Use Case: Directed Tokens
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2020 17:51:17 -0000

I think an on-device AS is an important use case, and we’ve seen work in the DID and SIOP space that there are plenty of smart agents out there that can help this. There’s a lot of interesting investigation in the app2app space right now as well, and I think that uncoupling the interaction method from the browser is a good step towards supporting that — but we should probably start a separate thread on that topic. 

Of course, a server-based AS is still a hugely important use case, so we can’t ignore that while looking at different kinds of deployment patterns as well. 

 — Justin

> On Jun 22, 2020, at 9:37 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:
> 
> In a perfect world the AS is controlled by the user as resource owner or agent. In my designs the AS is on the user's phone.
> 
> I like the term "Bound Token" better. It can contain many sub tokens as data or by reference.
> 
> Of course other use cases are supported.
> 
> thx ..Tom (mobile)
> 
> On Mon, Jun 22, 2020, 12:55 AM Denis <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> wrote:
> Hello Justin,
> 
> A few comments between the lines.
> 
>> One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can’t, or at least can’t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don’t know if this concept has a regular term, so I’m going to call it “directed access tokens” until we come up with something better — assuming we decide this is worthwhile.. 
> I don't understand what may mean "directed access tokens” but I understand what means "multiple access tokens". 
> When speaking of "multiple access tokens", these access tokens may come from one or more ASs.
> 
>> In OAuth, the client’s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.
>> 
>> But we’re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.
> As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.
> 
>> In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions about what that specific token is good for. This needs to be information outside the token itself, since I believe we want to keep OAuth 2’s feature of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn’t enough to tell the client what to do with the token if it doesn’t know already. 
>> 
>> I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I’ll try to summarize here, but I know the folks I’ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I’ve missed. 
>> 
>> (1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted. Everything is in a single security domain controlled by the AS,
> Speaking of "multiple access tokens" is in contradiction with single security domain "controlled" by an AS. 
> A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also 
> need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be 
> the "primary issuer" of a university diploma. It should not be either a "secondary issuer", because 
> the bank does not "need to know" what are the diplomas of the user.
> 
>> but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.
> There is no good reason why the AS should be involved in that step. 
> OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
> GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
> An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.
> 
> A client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. 
> 
>> (2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from.
> Once again, the client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it.
> 
>> There’s a cross-domain trust that’s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver’s license information, but doesn’t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn’t know yet who the user is.
> When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.
> 
>> The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at. 
>  A single AS should not be aware of all the attributes a user has. 
> 
>> 
>> As far as I know, in both of these cases, the token is only good for that API and not others — but more on that later.
>> 
>> A simple thing to do is just give back a URL with the access token, which tells the client where to go. 
>> 
>> 	{
>> 		“access_token”: {
>> 			“value”: “87yui843yfer”,
>> 			“resource_uri”: “https://example/foo <https://example/foo>"
>> 		}
>> 	}
>> 
>> This is good for some kinds of APIs, but it’s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that’s keyed on headers, or verbs, or any number of things. And it doesn’t tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it’s not universal. Do we want or need a universal description language for directing where tokens go?
>> 
>> This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?
>> 
>> This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?
>> 
>> I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can’t get in the way of this, because if it does, there’s very small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.
>> 
>> I’m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I’ve chatted with offline about this can join the conversation and provide more light than I was able to.
> The two use cases which are considered above are:
> 
> (1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted.
> (2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. 
> 
> That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.
> 
> Denis
> 
>> 
>>  — Justin
>> 
>> 
> 
> -- 
> Txauth mailing list
> Txauth@ietf.org <mailto:Txauth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth