Re: [OAUTH-WG] updated Distributed OAuth ID

Brian Campbell <> Wed, 13 June 2018 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 215F5130E8F for <>; Wed, 13 Jun 2018 14:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n18g-PAWVFSm for <>; Wed, 13 Jun 2018 14:43:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 958281271FF for <>; Wed, 13 Jun 2018 14:43:59 -0700 (PDT)
Received: by with SMTP id d185-v6so5061801ioe.0 for <>; Wed, 13 Jun 2018 14:43:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cCwchyvUlXEuvRTPisuXWH7I8X6svJy4FZSRMCsqfpA=; b=nZodvxLYajRCR8A+COfNxdbfvH9obzqsxry2wd36u0/GJpMeAr5cqQbLKEyrBFG/Fi c4XFS0PXnyWUt7Q9gB71uIZqA3Eeq0kcXD/fFKLXZfaJnu3UnJDEKxdoCGTPwAStf2hS HzyZG67/qef1bORyUOeaADQC5C73xI/12FBjY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cCwchyvUlXEuvRTPisuXWH7I8X6svJy4FZSRMCsqfpA=; b=Wzx74QPehA0uNPfqwdsfaQLG8/6yfjNOu4XGTvaUtyppEbmgvSJWPxnIy4WH0Cwpn6 rLKUrHLt+TsVkqd3ILQmC029sQYCOZT7o1ru6ZQdqCMD92SZXD6IFsf0D2L32RbzmCUS ZQx/vvdB25ahXxeRqRLnjFXnonVSoAb0SFZBdV8c/UWsJni8lMQ/OY6uQM1jjsE//KL3 fg+3jDId4t7thDVpjDoDr6NeytWvpsS88MgAZtsxzDZRlgqZiHquIK5A3MNO2uo+lBDQ aKV+ur5kdMoJPUJ9BVXjwrLukE1UvJ2VEYNWymKNhl7dr3WzsA23pqAaISOcS+JYQT6A PVZg==
X-Gm-Message-State: APt69E2++ZKNljWLJjpdeqoi/vjktIBCTVV3vg2PUxnROAHvcIOYt7sT NuqB1xp/B8SU9CKqLITpms1cElzOscfQ00wZeIAB1xkIacTVu1Chm8PesNw3AeLzGE7ei16Xzdr NInLrl1ZipZxxaQ==
X-Google-Smtp-Source: ADUXVKJlKzrKTGokkleRnC2jrDVzVbLIJe3HXWAqyYUooTbtLmFLEauxj76oI+RQolikKO9l0q8u1x7WxbmglWKTZWs=
X-Received: by 2002:a6b:d90e:: with SMTP id r14-v6mr6683015ioc.247.1528926238805; Wed, 13 Jun 2018 14:43:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:9785:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 14:43:28 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Brian Campbell <>
Date: Wed, 13 Jun 2018 15:43:28 -0600
Message-ID: <>
To: Jared Hanson <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="0000000000005a2941056e8ce1fb"
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: Wed, 13 Jun 2018 21:44:03 -0000

Thanks for the review and suggestions, Jared. A token (pun intended!)
attempt at addressing your comments follows.

Though I don't think I actually discussed it with my co-authors, I did
think about the link relation for the AS being the issuer rather than
pointing to the metadata document under ".well-known".  I must admit that I
kinda liked using the full URL to the metadata because it relieved the
client from having to figure it out from the issuer. Which could be
cumbersome for clients given that there's both
and the soon to be ".well-known/oauth-authorization-server" as well as
different procedures for forming the full metadata URL from the issuer
value when the issuer contains a path component. Having said that though,
I'm inclined to agree with you that the *right* thing to do here is have
the link relation to the AS be just the issuer value. Or at lest invite
more discussion about it. "oauth2-isser" seems a perfectly reasonable
relation name, should we take that route.

The idea behind the "resource_uri" link relation (and this likely needs to
be expanded on better in the document) is that it is like the base URL of
the application or set of protected resources. So, for example, both a
request to and might get a 401 with
resource_uri link relation value of <>. Or
a requests to and might both get a 401 with resource_uri
link relation value of <>. RFC6596 says in
the abstract that the "canonical" Link Relation is used to "designate an
Internationalized Resource Identifier (IRI) as preferred over resources
with duplicative content".  "canonical" doesn't seem to fit the purpose
from that text and reading RFC6596 didn't help me see it fit either. I
looked through the registry for Link Relation Types and nothing jumped out
at me as being applicable for this.

The client check of the host in the link relation to the host where the
request was made is intended to protect against what the draft calls
Resource Server Impersonation in 6.2 where a bad RS would return a 401 with
a link relation for a different sever which would result in the client
asking for a token for that different server but using it with the bad
server, who in turn could replay it at the different server. PoP tokens
could also prevent such replay in a different way but for bearer tokens I
think the check is needed to ensure the right audience gets into the token.

On Tue, Jun 12, 2018 at 4:57 PM, Jared Hanson <> wrote:

> 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 <>
> _______________________________________________
> OAuth mailing list

_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._