Re: [Txauth] New version of XYZ Draft

[Dick Hardt <[e-mail]>]

On Mon, Jul 20, 2020 at 4:26 AM Justin Richer <[e-mail]> wrote:

> Hi Dick,
>
> I think it should be pretty uncontroversial that the goal of the GNAP
> working group is to produce the GNAP protocol. But I’m still glad to see
> you’re interested in focusing on technical discussions.
>
> Answers to the individual points inline.
>
> On Jul 18, 2020, at 8:58 PM, Dick Hardt <[e-mail]> wrote:
>
> Justin: how about we let the chairs drive WG conversations on the
> goals, and we focus on the technical discussion?
>
> In addition to my questions and observations earlier, here is my feedback
> on the new capabilities in XYZ:
>
> 2.5.2. Redirect to an Arbitrary Short URL
>
> This looks the same as 2.5.1 except it is short. My concern with both of
> these is the AS has no signal on the mode chosen by the client/user. It
> could be a redirect on the same device, or decoupled, where the user is now
> on a different device. In 2.5.3 you justify a new URL because the AS may
> want a different URL for an app. I think that is even more significant
> between an on device redirect, and a decoupled experience. By having
> different URLs for the different modes in XAuth, the AS can ensure the one
> in a decoupled mode is short enough to be scanned if decoupled is
> supported. In other words, the mode dictates if it should be short enough
> to be scanned.
>
>
> The differences between a “coupled/decoupled” experience are not
> controlled by the “redirect/short_redirect/app” parameters, but by the
> “callback/pushback” parameters. The first three are parameters that
> determine some of the ways that the client can get :to: the AS, while the
> others are ways the client can get :back: from the AS. They are not tied
> together like they are in Xauth.
>
> Which combinations are available is up to the client’s request, since,
> after all, the client is the piece of software that knows what it can do,
> not the AS. The AS isn’t in a position to guess what the client is going to
> do with the information it gets back, it can only respond to the request
> for information that the client sends. If a client displays a URL to the
> user as a QR code, it’s probably not going to send a “callback”, for
> example. If an AS determines that it doesn’t want to support that
> “decoupled” mode for a given request, it can reject it for lack of a
> “callback” parameter. The reason for this decoupling
>

Looks like you might have not finished this sentence ... but you are
missing my point.

As noted below, the client may not know what it can do until it tries.

The user will often be the one that decides the actual flow that is
started. If the AS has an app, the user will want to use the device with
the AS, which may not be the device the client is on. The client can show a
QR code for the user to scan with their phone, or it can do a redirect to
the browser and get redirected back. The AS does not know which flow is
happening if the URL provided can do either of those.

I described this in:

https://mailarchive.ietf.org/arch/msg/txauth/qOF5Wl3uYQ9rdzEz7ORftYAAHc4/



>
> And as I’m sure you saw in my editor’s note, I’m not convinced that the
> short_redirect is worth it as a separate option, even though the semantics
> are pretty clear here. As I said in the last discussion we had on this
> topic, I’ve implemented a QR code based on a full redirect URI and did not
> find it problematic. You made a compelling argument that the AS would
> potentially have different generation rules for short and long, and
> wouldn’t want to use a short one unless it needed to. It seemed to be a
> simple enough addition to put in this revision.
>
>
> 2.5.3 Open an Application-specific URL
>
> What are you intending "app" to mean? I can think of a device where the
> client can open a URL, and a URL could not be associated with an
> application on the device. Are you thinking the client will do some
> detection if a specific app is available on the device? What if the app is
> not on the device? Most platforms don't provide any probing on what other
> apps are on a device, so there is no mechanism to detect if the app is
> present prior to launching. Is that what you are expecting?
>
>
> You can detect if an app (any app) is going to handle a URL on some
> platforms. This mechanism not only lets an AS have different URLs for app
> launching and web-based interaction, and it lets the client optimize the
> experience instead of the awkward fall-through that we have with OAuth2’s
> app2app communication today. Furthermore, as I’m sure you saw in my
> editor’s note, there’s probably going to be additional pieces of
> information passed in this case. I’ve talked with a couple different groups
> who are using distributed storage mechanisms to communicate between
> components. In that case, this will probably have more information in it
> than a single URL, but I didn’t want to conjecture what that would look
> like, thus the note.
>

I'm still not sure what you mean by app. Are you thinking only
mobile/tablet? PC? Media streaming device?

On iOS, the ability for an app to detect if a URL will be handled is
significantly limited. Last I checked, you could have 5 URLs in your app to
check. Apple locked it down to improve privacy.

FYI: On iOS, an app can attempt to open a deep link for an app and set a
flag so that the browser will NOT open the URL in the browser if the the
app is not installed. So the client can try opening another app, and if it
is not there, take another course of action, but it would know that until
it tries to open the other app.


>
>
> 2.5.5. Receive an HTTP Direct Callback
>
> What use cases require this functionality? Contrary to SecEvent, where
> both push and poll are specified because a receiver may not be able to have
> a public endpoint, the AS has a public endpoint for the client to call. In
> GNAP, the client can poll the AS. Why have both?
>
>
> Why limit the client to only callbacks? The callback means “there’s an
> HTTP endpoint that the user’s browser gets to” whereas pushback means
> “there’s an HTTP endpoint that the user’s browser can’t get to”. Both are
> reasonable, and should be combinable with any of the options for getting a
> user to the AS, above. There are likely to be other options as well, since
> we already see them in the wild (CIBA’s push mode, for instance).
>

"Why limit the client?"

This is a security protocol. More ways to do the same thing increases the
attack surface. It also increases  complexity / or lowers
interoperability.  The AS either needs to support ALL the mechanisms, or
there may not be interop if the client and AS don't support a common
mechanism.

ᐧ