Re: [OAUTH-WG] updated Distributed OAuth ID

Jared Hanson <> Tue, 12 June 2018 22:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FD9A130EA4 for <>; Tue, 12 Jun 2018 15:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hrvx2K1riDkP for <>; Tue, 12 Jun 2018 15:57:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C578128CF3 for <>; Tue, 12 Jun 2018 15:57:15 -0700 (PDT)
Received: by with SMTP id h10-v6so679389wrq.8 for <>; Tue, 12 Jun 2018 15:57:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mxLKSs+PxQqhO1MZlZbX/ClThljDPcV7uDdI5aePzM8=; b=BL/dE2PX8fMEyoa3b4AZ9sKHKowiBTUFCoPWpiDJcwrLpzwcoLWiS/5t1tWUTmWGgg VPSWIkyhE5twoWY65asIflV1CyCEo3EkTdYKG2L/dQNkWxwqDFyNp0Y5y0vWx0I7Paq1 ntOD4xBeg46xn/HDCvoPVemgh7rPjJq6+uDd1+HSRvQmAb/yABi2yfbCyV4iNxB/5HyQ /k2VEK7MHIUUTWOMvyAwXxUl7fib9SBAIajpFpFSb4wRMWoBCF5wKVlcLAYRQ0Igs8ym pW54owC5bzPo/DwnpUX1T9Uu9g4CSTDBmSpxTWJNDGO3iyWgKeqMBalKGIHWU+jJe0EC Eu7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mxLKSs+PxQqhO1MZlZbX/ClThljDPcV7uDdI5aePzM8=; b=pGtD15naBXkEP8oDM0Fry/ykbLUCuA/CXwdWrhiTq3+7kb/h/VP+vDkWSUyNOLWg+9 wPbiCoPJ0jIlwia17ym1tIS4aYgNTEUaSIgHsFyus2zvFQ2vMxsMvKdktbyuOtnQ3kwm DShzCBFpN2QDyRP/f7m0xjTR0xSNJLLqE3mAmFDw7kyaxA7ElGNXrSxVwe+k2Glhb80G ++oBtbzuR8+TwpuwRCKQxXRzI6wFYMefz0gEs66mZBfw2XttdHrSm0gmaqo+NKIqgTj9 +LwExwTf1aSaaQLgfnwImqXfxnz6Rn4okGMOQicReRYxGysbbBW4oQ1JUPPSbdBqLFMh 5ZDA==
X-Gm-Message-State: APt69E0C4+gtssJcyZxnT0QXP2N6acvaJn4m5SAEIu0OFY4QMRAXpw7c D0ZXZjm0s0JRN1lrTwvP6JEjFOekvioVvAGQ9g7IzOY2
X-Google-Smtp-Source: ADUXVKJJGXOz5fxQiHtoxBqBWF6MYDzakhor1Z7CBXXWgR6+GHfDHU9rZ/8GahekahSN4zNOny2tfqo2nWkyhsMSwkQ=
X-Received: by 2002:adf:9c12:: with SMTP id f18-v6mr2192617wrc.40.1528844233333; Tue, 12 Jun 2018 15:57:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:adf:8718:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 15:57:12 -0700 (PDT)
From: Jared Hanson <>
Date: Tue, 12 Jun 2018 15:57:12 -0700
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000071e150056e79c93e"
Archived-At: <>
Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jun 2018 22:57:20 -0000

Thanks Dick, Nat and Brian for your work on this ID.  I have a couple
improvements I would like to discuss:

I would suggest replacing the "oauth_server_metadata_uri" link relation
with "oauth2-isser", and dropping the ".well-known" suffix from the value.
For example:

Link: <>; rel="oauth2-issuer"

The rationale for this are two-fold:

1. It allows the discovery mechanism to be more flexible, or application
specific.  For instance, OpenID Connect discovery could be used and take
advantage of already deployed ".well-known/openid-configuration"
documents.  Applications could also take advantage of other discovery
mechanisms, either now (such as LRDD and WebFinger) or in the future.

2. It aligns the syntax (underscores vs dash) with
(which I also think should be revived as link relations).  Also, existing
conventions with registered link relations seem to prefer dashes rather
than underscores.

I would suggest replacing the "resource_uri" link relation with "canonical"
(RFC6596), which seems to fit the purpose and avoids registering a
potentially duplicative link relation value.

There is language in the draft requiring the client to check "host" values
between TLS certificates and link relation values.  This seems unnecessary
to me, for a couple reasons.

1. It unnecessarily constrains the logical organization of resources, which
may be hosted on multiple domains and yet have a canonical URL by which
other systems, including the authorization server, identify them.  Allowing
the canonical URL to differ from the host of the initial request will avoid
these limitations.

2. The resource server must ultimately do audience checking in order to
validate the access token.  I believe this accounts for all the security
considerations, and alleviates the burden from the client to do any
checking itself.

Jared Hanson
Auth0 Inc.

Jared Hanson <>