The difference between Redirect with Polling and Device with Polling

[ritou]

I think the difference between the two flows is only whether the URL is static or not.

• Device with Polling : user_code_url, user_code
• Redirect with Polling : interaction_url

If it is the same as "relation of verification_uri and verification_uri_complete" in the definition of Device Flow, whether the URL is static or not, I think that the device mode should be used when the RC directs the RO to the secondary device.

Proposal

• Redirect Mode
  • Request : type:interaction, callback, state params are required
• Device Mode
  • Request : type:device are required
  • Response : user_code_url + user_code or user_code_url

[jricher]

That's the key difference -- whether the URL is arbitrary. The verification_uri_complete isn't exactly the same as the interaction_url because the former is specified to be a composition of the verification URI and user code, where the latter is an arbitrary URI. The thing is, in OAuth2 we couldn't really re-use the authorization endpoint in this way because it would require the client to put a bunch of things onto it, but in XYZ it's already a fully formed URL handed to the client by the AS.

What you propose is exactly what was there previously, but I realized that we didn't need the extra complexity of having a fully-composed URL and we could use an existing mechanism. Ultimately it's all about what the client can convey to the user and get the user to do.

I'm on the fence about the type field, because ostensibly you could use both together. Open to suggestions on a better way to convey this.

[ritou]

The verification_uri_complete isn't exactly the same as the interaction_url because the former is specified to be a composition of the verification URI and user code, where the latter is an arbitrary URI.

Thanks, I understand the difference.

I'm on the fence about the type field, because ostensibly you could use both together. Open to suggestions on a better way to convey this.

A value of "redirect" will make the developer imagine browser redirects (or pop-up). If similar UX is provided in device mode and redirect mode without callback and state, the type field may not be necessary.

This is a suggestion not to use the type field.

# open browser and redirect back to RC
{
    "interact": {
        "callback": "https://client.foo",
        "state": "VJLO6A4CAYLBXHTR0KRO"
    }
}

When using a secondary device, the request includes only whether to use the user code.

# use secondary device
{
    "interact": {
        "user_code": (boolean)
    }
}

[jricher]

What I realized in the latest revision is that there are two different aspects here:

1) How the client gets the user over to the AS. Options here are sending them to an arbitrary URL or sending them to a static URL and having them type a code.

2) How the user gets back to the client after interacting. Options here are getting redirected back (the callback + state, which maybe should be combined but for now they're separate), or ... not getting redirected back. Polling is allowed in both cases anyway. There also needs to be something like CIBA Push mode in here, but I haven't fully thought that through yet.

[ritou]

I talked about this protocol with a Japanese Identity developer.

or ... not getting redirected back.

If the Interaction response does not return to the Client, there are threats such as the initial OAuth 1.0 Session Fixation Attack or OAuth 2.0 Device Flow Remote Phishing. OAuth 1.0 returns the interaction handle to the client by the user, and the client needs an endpoint to receive it. The measures defined in Device Flow are the device information display on the authorization screen and the client side user code display.

Do you define such measures in XYZ?

[jricher]

The fixation attack form OAuth 1.0 doesn't exist because the return in the front channel always has the interaction handle. If you're doing a polling mechanism in XYZ, you would need some additional mechanism for handling these attacks in a secure fashion. I think there are potential options here including the confirmation code display that CIBA uses: once the user enters their code, display a confirmation code to the user who then has to manually check it on their device.

Granted, the same scenario is actually a desirable feature sometimes -- when you've got one user authorizing an application that another user is using.