Re: [Txauth] Use Case: Directed Tokens

[Tom Jones <[e-mail]>]

I am getting tired of the whack-a-mole approach of JAR this and RAR that,
what's next BAR, FAR, STAR ad infinitum? Can't we just define a bound token
type as a high order spec and then just riff on it instead of a full
standard for each and every iteration each with their own security and
privacy considerations? If we don't the number of id/az tokens will expand
in the same manner.
Peace ..tom


On Tue, Jun 23, 2020 at 10:51 AM Justin Richer <[e-mail]> wrote:

> 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 <[e-mail]>
> 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 <[e-mail]> 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"
>> }
>> }
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>