Early Review of draft-ietf-mailmaint-oauth-public-05
review-ietf-mailmaint-oauth-public-05-secdir-early-jones-2026-08-16-00

SecDir early review of draft-ietf-mailmaint-oauth-public-05

Document: draft-ietf-mailmaint-oauth-public-05
Title: OAuth Profile for Open Public Clients
Reviewer: Michael B. Jones
Review result: Has Issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

MAJOR ISSUES

3.3. Dynamic Client Registration says:
    The redirect URI restrictions MUST be enforced. These ensure the OAuth flow
    can only be completed by native clients — not web clients.

If this profile is only useful for Native Clients and not Web Clients, I
believe you should be much clearer about this in the Abstract and Introduction
and say why you are placing this restriction in the Introduction.  This is too
big a restriction to have buried only in a clause about Dynamic Client
Registration.

5.1. Interoperable OAuth Scopes Registry

There needs to be language about when support for the registered interoperable
scopes is supported by general OAuth implementations versus when support is
required only when supporting particular profiles, such as the one defined by
this specification.  This may also affect the Registration Procedure
instructions.

This is a major addition to OAuth.  As such, it needs to be brought to the
attention of the OAuth working group and reviewed there.  (You can do that
after you add the explanatory text I'm asking for here and in the next section,
as that will help the OAuth working group review be more productive.)

I suspect you may be asked to change the title of the registry from
"Interoperable OAuth Scopes" to something like "Mail Maintenance OAuth Scopes"
so that it's clear what the scope of applicability of this registry is.

5.1.1. Registration Procedure

Please specify that registration requests use the oauth-ext-review@ietf.org
mailing list as other OAuth registries do.  I suggest copying the registration
instructions at
https://www.rfc-editor.org/rfc/rfc9728.html#name-iana-considerations, modifying
them only as necessary for your registry.

You should also provide instructions to the designated experts on when the
urn:ietf:params:oauth:scope:* naming convention must be used, such as
urn:ietf:params:oauth:scope:mail, and when unstructured strings may be used,
such as offline_access.

MINOR ISSUES

3.1. Overview, list item 3 says:
    3. The client instance authorizes using the Authorization Code Grant flow
    ([RFC6749], Section 4.1) with PKCE [RFC7636] and Issuer Identification
    [RFC9207]. The client instance also sends Resource Indicators [RFC8707],
    however server support for this is RECOMMENDED.

What is the implication of "however server support for this is RECOMMENDED"?
What happens if the server doesn't support Resource Indicators?

3.2. Fetching the Authorization Server Metadata says:
    If a path is present, it MUST NOT contain . or .. segments, MUST NOT end
    with a trailing slash

Does this mean that issuer identifiers with a path consisting of "/" such as
https://as.example.com/ MUST NOT be used and instead https://as.example.com
MUST be used?  The spec should be clear about that.

3.4. Authorization says:
    After constructing the authorization request URL, the app uses
    platform-specific APIs to open it in an external user-agent.

You should explain the restriction to external user-agents and why a user-agent
built into the application MAY NOT be used.  Also, is this restriction
enforceable?

3.4. Authorization says:
    Other URL parameters MAY be supplied but will be ignored.

This is underspecified.  What kinds of other URL parameters are you referring
to?  redirect_uri values?  Also, why is it safe to ignore them, rather than
rejecting them, per the redirect_uri matching rules?

3.8. Getting a New Access Token

In "You cannot share a refresh token between devices.", change "cannot" to
"MUST NOT".

3.9. Token Expiry Times says:
    If the refresh token is revoked, all existing stateful connections MUST
    immediately be closed.

Detecting refresh token revocation isn't possible until the refresh token is
used, so this requirement isn't possible to fulfill, as written.  Please update
to say that stateful connections MUST be closed once revocation of the refresh
token is detected.

3.10. Client Id Validity

Change "which MAY be different to the previous time" to "which MAY be different
than the previous client id".

4. Security Considerations

When referencing RFC 6819, also reference RFC 9700/BCP 240.

4. Security Considerations

Add a reference for passkeys - possibly [WebAuthn].

4. Security Considerations says:
    The attacker defines the real authorization_endpoint and token_endpoint,
    but their own resource servers.

This is not grammatically correct.  Do you mean to say, "The attacker uses the
real authorization_endpoint and token_endpoint values in its metadata, but uses
their own resource servers."?

Similarly, please correct the ungrammatical sentence "The attacker defines the
real authorization_endpoint and resource servers, but their own token_endpoint."

4. Security Considerations

Change "Implementors" to "Implementers".

5.1.3. Initial Registry Contents

Correct "OpenID connect" to "OpenID Connect".

5. IANA Considerations

This specification defines many values in the urn:ietf:params:oauth: namespace
without registering them in the IANA OAuth URI registry at
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#uri. 
Please register them.

6. Normative References

Please correct the WebAuthn reference to:

        <reference anchor="WebAuthn"
        target="https://www.w3.org/TR/2021/REC-webauthn-2-20210408/">
          <front>
            <title>Web Authentication: An API for accessing Public Key
            Credentials - Level 2</title> <author initials="J."
            surname="Hodges" fullname="Jeff Hodges" role="editor">
              <organization>PayPal</organization>
              <address>
                <email>jdhodges@google.com</email>
              </address>
            </author>
            <author initials="J.C." surname="Jones" fullname="J.C. Jones"
            role="editor">
              <organization>Mozilla</organization>
              <address>
                <email>jc@mozilla.com</email>
              </address>
            </author>
            <author initials="M.B." surname="Jones" fullname="Michael B. Jones"
            role="editor">
              <organization>Microsoft</organization>
              <address>
                <email>mbj@microsoft.com</email>
                <uri>http://self-issued.info/</uri>
              </address>
            </author>
            <author initials="A." surname="Kumar" fullname="Akshay Kumar"
            role="editor">
              <organization>Microsoft</organization>
              <address>
                <email>akshayku@microsoft.com</email>
              </address>
            </author>
            <author initials="E." surname="Lundberg" fullname="Emil Lundberg"
            role="editor">
              <organization>Yubico</organization>
              <address>
                <email>emil@yubico.com</email>
              </address>
            </author>
            <date day="8" month="April" year="2021"/>
          </front>
        <refcontent>W3C Recommendation</refcontent>
        </reference>

7. Informative References

Please correct the OpenID Connect Discovery reference to:

      <reference anchor="OpenID.Discovery"
      target="https://openid.net/specs/openid-connect-discovery-1_0.html">
        <front>
          <title>OpenID Connect Discovery 1.0</title>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NAT.Consulting (was at
            NRI)">NAT.Consulting</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Yubico (was at Ping
            Identity)">Yubico</organization>
          </author>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Self-Issued Consulting (was at
            Microsoft)">Self-Issued Consulting</organization>
          </author>

          <author fullname="Edmund Jay" initials="E." surname="Jay">
            <organization abbrev="Illumila">Illumila</organization>
          </author>

          <date day="15" month="December" year="2023"/>
        </front>
      </reference>

Please correct the OpenID Connect Core reference to:

      <reference anchor="OpenID.Core"
      target="https://openid.net/specs/openid-connect-core-1_0.html">
        <front>
          <title>OpenID Connect Core 1.0</title>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NAT.Consulting (was at
            NRI)">NAT.Consulting</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Yubico (was at Ping
            Identity)">Yubico</organization>
          </author>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Self-Issued Consulting (was at
            Microsoft)">Self-Issued Consulting</organization>
          </author>

          <author fullname="Breno de Medeiros" initials="B." surname="de
          Medeiros">
            <organization abbrev="Google">Google</organization>
          </author>

          <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
            <organization abbrev="Disney (was at
            Salesforce)">Disney</organization>
          </author>

          <date day="15" month="December" year="2023"/>
        </front>
      </reference>

Acknowledgements

Please add an Acknowledgements section listing non-editors who have contributed
to the specification.  An example Acknowledgements section can be found at
https://www.rfc-editor.org/rfc/rfc9700.html#name-acknowledgements.