Re: [Txauth] Interact Section

[Justin Richer <[e-mail]>]

XYZ doesn’t look at interaction in terms of “flows” but instead in terms of discrete capabilities, and this is a deliberate move beyond what OAuth 2 allows for. Each member of the interaction request represents one piece of the whole set of capabilities the client is able to do. For what’s in there right now:


redirect: this tells the AS that the client can get the user to an arbitrary URL, determined at runtime by the AS. This URL is taken as a whole without the client doing anything to it. The client can do whatever makes the most sense for the client in order to get that user to the URL. It could redirect them, it could open up a browser, it could display a scannable code, it could email them a link to click on, etc. Importantly, this says nothing about how the user gets back — more on that in a minute. This could be renamed “arbitarily_long_url” or something more general.

user_code: this tells the AS that the client can tell the user about a short user-typable code and direct them to a static URL that the client should be able to know outside of the protocol. It doesn’t say anything about how the client gets the user there, and it doesn’t say anything about how the user gets back. 

callback: this tells the AS that the client can receive a response on the given URL when the client is done interacting with the AS. It says nothing about how the user got there — they could have gone to an arbitrary URL via redirect, they could have gone to a static URL and entered a code, they could have gotten a push notification to a different application they have installed. What’s important here is that this allows the client and AS to prevent certain kinds of attacks, including session fixation, by coupling a front-channel response with a back-channel response. 

didcomm/didcomm_query: these tell the AS that the client could speak the DIDCOMM protocol to pass messages around to an agent via some kind of DID-enhanced communication fabric. The XYZ spec is light on details here because, to me, these are largely examples of what else could be done outside of HTTP. If we brought these into the eventual GNAP specification I would expect them to be in their own DIDCOMM-focused interaction extension. I really wasn’t trying to hide the extensibility within the DIDCOMM specs; I would much rather we be clear about how things work together in our own spec than to punt all extensibility to external groups and claim success.

But now that you have the parts, in order to make the ‘flows” you have below, you combine these capabilities and probably invent a few other interaction methods to add to them. That’s where the extensibility of this model really comes into play: you don’t define a comprehensive “flow” with all of the interaction parts, you define what new parts you need and use them in combination to solve your use case. This allows you to re-use well-defined behaviors, and for all behaviors to have pretty narrow scopes and expectations of use.

There are a few potential future interaction options that I think deserve some thought at some point within the group:

webauthn: basically a way for the client to propose a webauthn challenge/response to the AS. The AS would respond to the initial request with a challenge to be signed, and the client would sign it and return it directly after having interacted with the user to unlock their key store. So really I mean any number of FIDO-style key stores and devices here.

password: as much as I hate this, someone’s going to want to have the client prompt for credentials directly with the user in an interaction mechanism, equivalent to the resource owner password grant in OAuth 2. I do not think this should be in the core, if we tackle it at all in this group, but we should at least discuss it because I guarantee people will ask for it.

callback_push: this would give the AS a URL that it could call directly to push a response to, instead of having the client poll for it. There are some interesting implications with HTTP2 and HTTP3 that we could make use of here, and if this all ever is translated on top of COAP then there are even more ways to push data. I think this fits with part of your “decoupled” flow below.

callback_ping: this would be a callback URL that didn’t do the cryptographic protection, because it would be something the client could detect was hit but couldn’t get data from it beyond that ping. We could accomplish this today by making the client nonce optional in XYZ and defining how it works with and without that, but I’m not sure I like that amount of subtlety, and the fact that it would fail to a more insecure method. 

app2app: this would tell the AS that the client wants to open another application, and not a webpage. The funny thing is that today on a mobile platform that’s usually done through an HTTPS URL that’s captured by the app. There’s a lot of thinking that needs to happen here, but it’s an area of active interest outside of this group, and I’ve personally got meetings with several clients this week alone to discuss this use case and need.


There are other protocols and communication methods here that are possible, especially, as you say, when we start thinking about the capabilities of smart devices. I think there’s even a way to bootstrap a self-issued-OP style flow but I haven’t chased down the details on that enough to be comfortable trying to plot it out, yet.

 — Justin


> On Jun 10, 2020, at 11:12 PM, Francis Pouatcha <fpo=[e-mail]> wrote:
> 
> The interact section of the <<draft-richer-transactional-authz-08>> sort of defines the choreographie of the authorization process (flow). I am missing something like:
> 
> - A redirect flow 
> here the AS instructs the RC to redirect to RO to the given interaction URL.  Upon completing the RO interaction, the RO will be redirected back to the callback.uri specified by the RC. SO there is no callback here.
> 
> - A decoupled flow 
> is actually not visible. This is, I assume upon receiving the  <<transaction authorization request>>, the AS initiated an interaction with the RO (-device). Upon completion of the interaction with the RO, the AS invokes the provided callback.uri to deliver the token (authorization) used by the RC to proceed with  the transaction request>>.
> 
> - An embedded flow
> seems hidden behind the didcom section. With the evolding number smart devices, the embedded flow shall open room for different types of synchronous transaction authorization requests in which the RO gives a verifiable assertion (proof of possession) to the RC for use at the <<transaction authorization endpoint>> in exchange for the seeked access token. This assertion can range from a simple password to a cryptographically signed claim.
> 
> "interact": {
>   "embedded":[{
>       "mode":"encrypted password"
>     },
>     {
>       "mode":"didcom"
>     }],
>    "redirect":[{
>       "callback": {
>         "uri": "https://example.com/rc-front-channel/123456 <https://example.com/rc-front-channel/123456>",
>         "nonce": "VJLO6A4CAYLBXHTR0KRO"
>       }
>     }],
>     "decoupled": [{
>       "callback": {
>         "uri": "https://example.com/rc-back-channel/123456 <https://example.com/rc-back-channel/123456>",
>         "nonce": "VJLO6A4CAYLBXHTR0KRO"
>       }
>     }]
> }
> 
> Still no idea on how to express the RC flow preferences to the AS. Maybe the order of entries in the interact sesion
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>-- 
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth