[OAUTH-WG] Eric Rescorla's No Objection on

[William Denniss]

Thank you for your review. Changes to address your comments are staged
<https://github.com/WilliamDenniss/draft-ietf-oauth-native-apps/pulls> for
v12.

----------------------------------------------------------------------
----------------------------------------------------------------------
Document: draft-ietf-oauth-native-apps-11.txt
S 7.
To fully support this best practice, authorization servers MUST
support the following three redirect URI options. Native apps MAY
use whichever redirect option suits their needs best, taking into
account platform specific implementation details.
It's not entirely clear from this text what "support" means. Would
just echoing whatever redirect URI the client provided count as
support?

One way to implement client registration on the server is to have a
public/public client type field, and an arbituary list of redirect URIs. So
more or less, yes, you can support it by echoing whatever redirect the
client registered. There are some specifics involved though, like the
loopback type needs to support a wildcard port for example.

In practice, many authorization servers place restrictions on the types of
URIs that can be registered for different platforms (for example, Google
and Microsoft both do this). I've also seen arbitrary restrictions in OSS
servers that limited the ability to use with native apps, so I felt it was
worth explicitly calling out. There are also different security
implications of each redirect URI type.

I've revised the text to:

To fully support this best practice, authorization servers MUST
offer
at least the following three redirect URI options to native apps.
Native
apps MAY use whichever redirect option suits their needs best,
taking
into account platform specific implementation details.

S 7.2.

App-claimed HTTPS redirect URIs have some advantages in that the
identity of the destination app is guaranteed by the operating
system. For this reason, they SHOULD be used in preference to the
other redirect options for native apps where possible.
You should probably be clearer on who this guarantee is provided to.

I've updated the text. The guarantee is to the authorization server that
performed the redirect.

And I assume this SHOULD is directed to app authors?

Yes, updated.

Claimed HTTPS redirect URIs function as normal HTTPS redirects from
the perspective of the authorization server, though as stated in
Section 8.4, it is REQUIRED that the authorization server is able to
distinguish between public native app clients that use app-claimed
HTTPS redirect URIs and confidential web clients.
S 8.4 doesn't seem clear on how one makes this distinction. Is
it just a matter of remembering what the app author told you?

I reworked this section to make the point that the HTTPS URIs are
indistinguishable so you'll need to use the client type from registration
to distinguish.

S 8.1.
As most forms of inter-app URI-based communication send data over
insecure local channels, eavesdropping and interception of the
authorization response is a risk for native apps. App-claimed HTTPS
redirects are hardened against this type of attack due to the
presence of the URI authority, but they are still public clients and
the URI is still transmitted over local channels with unknown
security properties.
I'm probably missing something, but I'm not sure what this last
sentence means. Is the channel here the one that kicks off the
native app with the HTTPS URI as the target?

Yes.

I re-worked this section so it flows a bit better and has less duplication,
hopefully I resolved this ambiguity.