Re: [OAUTH-WG] Eric Rescorla's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

[William Denniss <[e-mail]>]

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

Replies inline:


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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.