Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDE0130E29 for ; Thu, 19 Jul 2018 06:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksTtyqyqQN4v for ; Thu, 19 Jul 2018 06:42:34 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE801130E0D for ; Thu, 19 Jul 2018 06:42:34 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id n7-v6so3809589pgq.4 for ; Thu, 19 Jul 2018 06:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hxM4cMXhK9flqvJA9J4U3+kdwDL47jQkJ3K2j36CNQY=; b=aJyzkVxWqFh45P8wMfE2C3Yxj3tHpTh7LbI94Wk/HG+Um4hYVO8ICpVLmhrFU5AT0K cBvmZpngUqre8PDizwiz1H2KBvQ8+R4qxcttMmYiBMwrcaCoDtmOW9QFbSWgB7QsFRxe ezXTBb3VIWALxeeDdgtstYMwEzKGGICJjTz4vqDFP96m1wCAxrJCy1TAVVwdwHl+XjGj y9JhiITydHRPQLw/kbGKKw/zhW+SZaBc9aMf4heWblLbir4sFoafiMnckg8mrWAJ7MVS hQMbhgqLoVPLm1vkuWPefg21sdJnIVWFLmoGmnzrNOvKRafY/lzjK0Z99geHvHCTZgNN 6zIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hxM4cMXhK9flqvJA9J4U3+kdwDL47jQkJ3K2j36CNQY=; b=iI21aszTiYtwk6ODU6C04VOw++3MrfVeb/x85RWCFFLoxXNqB8jqtjXLtA/ZmI52ap ISsGWLzMCo86rbJTsChlQuTbJYEUgI1epm3nBM4UFyIx3XCVHTmYp/2bHjQTg3RvVUN0 vKt8iWcRrNIxKHKTkuJZqJ5uJF9IAMhtUc9gAt1ur+HusPpksFTt04Yx8scswoq1aJOu pUng+V7IJM2hAflgQWpLZ5V7dsOHAJoDmmJ3vZtWfQVf3lkaNk/G/LhVCBP8BqUAWR7B oMESlX1hPU30l3aJwpN41iRLJ9ree297VYYM7QFnBPj926dJV8CrmTA89hUwZHkrTBzP 7Ixg== X-Gm-Message-State: AOUpUlG8lvQh1epB8iOttJzcNZ4GL6rlrXhvg2OI/ips2xjQRNr8A1ih TtJQRMtOp+POq1fTpdZamhAtR1/93SSmpvTm1o2iAa4Y X-Google-Smtp-Source: AAOMgpf1mBZPhHsg39h7pHFeX6qkOhQ27mFPqmlW+pzj3mFR+YC4ESiC+ezGhAKgNBC2LUV6tDOiyy3tLDYMh/VOL3s= X-Received: by 2002:a62:be03:: with SMTP id l3-v6mr9572250pff.138.1532007754185; Thu, 19 Jul 2018 06:42:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Thu, 19 Jul 2018 06:42:13 -0700 (PDT) In-Reply-To: <1AD25F21-4F76-41CA-96E8-6E09373D04E8@alkaline-solutions.com> References: <1AD25F21-4F76-41CA-96E8-6E09373D04E8@alkaline-solutions.com> From: Dick Hardt Date: Thu, 19 Jul 2018 09:42:13 -0400 Message-ID: To: David Waite Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000fb41d205715a599a" Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 13:42:38 -0000 --000000000000fb41d205715a599a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable David, thanks for the detailed feedback ... responses inline ... On Thu, Jul 19, 2018 at 3:54 AM, David Waite wrote: > Four comments. > > First: What is the rationale for including the parameters as Link headers > rather than part of the WWW-Authenticate challenge, e.g.: > > WWW-Authenticate: Bearer realm=3D"example_realm", > scope=3D"example_scope", > error=3D=E2=80=9Cinvalid_token", > resource_uri=3D"https://api.example.com/resource", > oauth_server_metadata_uris=3D"https://as.example.com/.well- > known/oauth-authorization-server https://different-as.example. > com/.well-known/oauth-authorization-server" > > > My understanding is that the RFC6750 auth-params are extensible (but not > currently part of any managed registry.) > > One reason to go with this vs Link headers is CORS policy - exposing Link > headers to a remote client must be done all or nothing as part of the COR= S > policy, and can=E2=80=99t be limited by the kind of link. > > Nat had a good argument for using Link headers, I'll let him respond. > Second: (retaining link format) Is there a reason the metadata location i= s > specified the way it is? It seems like > > ; > rel=3D=E2=80=9Coauth_server_metadata_uri" > > should be > > ; rel=3D=E2=80=9Coauth_issuer" > > OAuth defines the location of metadata under the .well-known endpoint as = a > MUST. An extension of OAuth may choose from at least three different > methods for handling extensions beyond this: > 1. Add additional keys to the oauth-authorization-server metadata > 2. Add additional resources to .well-known for clients to supporting thei= r > extensions to attempt to resolve, treating =E2=80=98regular=E2=80=99 OAut= h as a fallback. > 3. Define their own parameter, such as rel=3D=E2=80=9Cspecialauth_issuer= =E2=80=9D, > potentially using a different mechanism for specifying metadata > > Given all this, it seems appropriate to only support specifying of > metadata-supplying issuers, not metadata uris. > Interesting, what do others think of this? There is a security advantage of using a predefined path as a malicious RS can not have the client fetch a different meta data document than the one that is at the well known location. > > Third: I have doubts of the usefulness of resource_uri in parallel to bot= h > the client requested URI and the Authorization =E2=80=9Crealm=E2=80=9D pa= rameter. > > As currently defined, the client would be the one enforcing (or possibly > ignoring) static policy around resource URIs - that a resource URI is > arbitrary except in that it must match the host (and scheme/port?) of the > requested URI. The information on the requested URI by the client is not > shared between the client and AS for it to do its own policy verification= . > It would seem better to send the client origin to the AS for it to do > (potential) policy verification, rather than relying on clients to > implement it for them based on static spec policy. > > The name =E2=80=9Cresource URI=E2=80=9D is also confusing, as I would exp= ect it to be the > URI that was requested by the client. The purpose of this parameter is a > bit confusing, as it is only defined as =E2=80=9CAn OAuth 2.0 Resource En= dpoint > specified in [RFC6750] section 3.2 - where the term doesn=E2=80=99t appea= r in 6750 > and there does not appear to be a section 3.2 ;-) > > It seems that: > a. If the resource_uri is a direct match for the URI requested for the > client, it is redundant and should be dropped > (If the resource URI is *not* a direct match with the URI of the > resource requested by the client, it might need a better name). > It is not a direct match. Open to new name suggestions! > b. If the resource URI is meant to provide a certain arbitrary grouping > for applying tokens within the origin of the resource server, what is its > value over the preexisting =E2=80=9C realm=E2=80=9D parameter? > It is not arbitrary. The resource URI MUST be contained in the URI the client is requesting access to. The hostname in the resource URI must be in the hostname in the TLS certificate. This lets the client ensure it is requesting an access token that is intended for the resource it is accessing. The realm parameter does not have these characteristics specified, and may already be used for other purposes. > c. If the resource URI is meant to provide a way for an AS to allow > resources to be independent, identified entities on a single origin - I= =E2=80=99m > unsure how a client would understand it is meant to treat these resource > URIs as independent entities (e.g. be sure not to send bearer tokens mint= ed > for resource /entity1 to /entity2, or for that matter prevent /entity1 fr= om > requesting tokens for /entity2). > It is intended for the client to enforce. > > Admittedly based on not fully understanding the purpose of this parameter= , > it seems to me there exists a simpler flow which better leverages the > existing Authentication mechanism of HTTP. > > A request would fail due to an invalid or missing token for the realm at > the origin, and and the client would make a request to the issuer includi= ng > the origin of the requested resource as a parameter. Any other included > parameters specified by the WWW-Authenticate challenge understood by the > client (such as =E2=80=9Cscope=E2=80=9D) would also be applied to this re= quest. > > Normal authorization grant flow would then happen (as this is the only > grant type supported by RFC6750). Once the access token is acquired by th= e > client, the client associates that token with the =E2=80=9Crealm=E2=80=9D= parameter given > in the initial challenge by the resource server origin. Likewise, the =E2= =80=98aud=E2=80=99 > of the token as returned by a token introspection process would be the > origin of the resource server. > > It seems any more complicated protected resource groupings on a resource > server would need a client to understand the structure of the resource > server, and thus fetch some sort of resource server metadata. > I'm not understanding why you think this. Would you elaborate? > > Fourth and finally: Is the intention to eventually recommend token bindin= g > here? Token binding as a requirement across clients, resources, and the > authorization servers would isolate tokens to only being consumed within = an > origin. This would actually make redundant/supplemental the AS additions > defined within this spec (resource/origin request parameter, =E2=80=98aud= =E2=80=99 > introspection response member) > Token binding solves part of the resource constrained access token requirement, but does not solve how the client authenticates to the AS. > > -DW > > On Jun 12, 2018, at 1:28 PM, Dick Hardt wrote: > > Hey OAuth WG > > I have worked with Nat and Brian to merge our concepts and those are > captured in the updated draft. > > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ > > We are hopeful the WG will adopt this draft as a WG document. > > Any comments and feedback are welcome! > > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --000000000000fb41d205715a599a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
David, thanks for the detailed feedback ... responses inli= ne ...=C2=A0

On Th= u, Jul 19, 2018 at 3:54 AM, David Waite <david@alkaline-solutio= ns.com> wrote:
Four comments.
<= br>
First: What is the rationale for including the parameters as = Link headers rather than part of the WWW-Authenticate challenge, e.g.:

WWW-Authenticate: Bearer realm=3D"example_realm",<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope=3D"example_scope",=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0error=3D=E2=80=9Cinvalid_token&quo= t;,
=C2=A0 =C2=A0 resource_uri=3D"https://api.example.com/resource<= /a>",


=
My understanding is that the RFC6750 auth-params are extensible = (but not currently part of any managed registry.)

=
One reason to go with this vs Link headers is CORS policy - exposing L= ink headers to a remote client must be done all or nothing as part of the C= ORS policy, and can=E2=80=99t be limited by the kind of link.

Nat had a good argument= for using Link headers, I'll let him respond.
=C2=A0
Second: (retaining link format) Is = there a reason the metadata location is specified the way it is? It seems l= ike

<https://as.example.com/.w= ell-known/oauth-authorization-server>; rel=3D=E2=80=9Coaut= h_server_metadata_uri"

should be

<https://as.example.com>; rel=3D=E2=80=9Coauth_issuer"

OAuth defines the location of metadata under the= .well-known endpoint as a MUST. An extension of OAuth may choose from at l= east three different methods for handling extensions beyond this:
1. Add additional keys to the oauth-authorization-server metadata
2. Add additional resources to .well-known for clients to supporting thei= r extensions to attempt to resolve, treating =E2=80=98regular=E2=80=99 OAut= h as a fallback.
3. Define their own parameter, such as rel=3D=E2= =80=9Cspecialauth_issuer=E2=80=9D, potentially using a different mechanism = for specifying metadata

Given all this, it seems a= ppropriate to only support specifying of metadata-supplying issuers, not me= tadata uris.

Interesting,= what do others think of this?

There is a security= advantage of using a predefined path as a malicious RS can not have the cl= ient fetch a different meta data document than the one that is at the well = known location.
=C2=A0

Third: I have doubts of the usefulness of resource_uri in parallel= to both the client requested URI and the Authorization =E2=80=9Crealm=E2= =80=9D parameter.

As currently defined, the = client would be the one enforcing (or possibly ignoring) static policy arou= nd resource URIs - that a resource URI is arbitrary except in that it must = match the host (and scheme/port?) of the requested URI. The information on = the requested URI by the client is not shared between the client and AS for= it to do its own policy verification. It would seem better to send the cli= ent origin to the AS for it to do (potential) policy verification, rather t= han relying on clients to implement it for them based on static spec policy= .

The name =E2=80=9Cresource URI=E2=80=9D is also = confusing, as I would expect it to be the URI that was requested by the cli= ent. The purpose of this parameter is a bit confusing, as it is only define= d as =E2=80=9CAn OAuth 2.0 Resource Endpoint specified in [RFC6750] section= 3.2 - where the term doesn=E2=80=99t appear in 6750 and there does not app= ear to be a section 3.2 ;-)

It seems that:
a. If the resource_uri is a direct match for the URI requested for the c= lient, it is redundant and should be dropped
=C2=A0 =C2=A0 (If th= e resource URI is *not* a direct match with the URI of the resource request= ed by the client, it might need a better name).

It is not a direct match. Open to new name suggestions!
=C2=A0
b. If the resource URI is mea= nt to provide a certain arbitrary grouping for applying tokens within the o= rigin of the resource server, what is its value over the preexisting =E2=80= =9C=C2=A0realm=E2=80=9D parameter?

<= div>It is not arbitrary. The resource URI MUST be contained in the URI the = client is requesting access to. The hostname in the resource URI must be in= the hostname in the TLS certificate. This lets the client ensure it is req= uesting an access token that is intended for the resource it is accessing.<= /div>

The realm parameter does not have these characteri= stics specified, and may already be used for other purposes.
=C2= =A0
c. If the resource URI is meant to provi= de a way for an AS to allow resources to be independent, identified entitie= s on a single origin - I=E2=80=99m unsure how a client would understand it = is meant to treat these resource URIs as independent entities (e.g. be sure= not to send bearer tokens minted for resource /entity1 to /entity2, or for= that matter prevent /entity1 from requesting tokens for /entity2).

It is intended for the client to enfor= ce.
=C2=A0

Adm= ittedly based on not fully understanding the purpose of this parameter, it = seems to me there exists a simpler flow which better leverages the existing= Authentication mechanism of HTTP.=C2=A0

A request= would fail due to an invalid or missing token for the realm at the origin,= and and the client would make a request to the issuer including the origin= of the requested resource as a parameter. Any other included parameters sp= ecified by the WWW-Authenticate challenge understood by the client=C2=A0(su= ch as =E2=80=9Cscope=E2=80=9D) would also be applied to this request.
=

Normal authorization grant flow would then happen (as t= his is the only grant type supported by RFC6750). Once the access token is = acquired by the client, the client associates that token with the =E2=80=9C= realm=E2=80=9D parameter given in the initial challenge by the resource ser= ver origin. Likewise, the =E2=80=98aud=E2=80=99 of the token as returned by= a token introspection process would be the origin of the resource server.<= /div>

It seems any more complicated protected resource g= roupings on a resource server would need a client to understand the structu= re of the resource server, and thus fetch some sort of resource server meta= data.

I'm not underst= anding why you think this. Would you elaborate?
=C2=A0

Fourth and finally: Is the intenti= on to eventually recommend token binding here? Token binding as a requireme= nt across clients, resources, and the authorization servers would isolate t= okens to only being consumed within an origin. This would actually make red= undant/supplemental the AS additions defined within this spec (resource/ori= gin request parameter, =E2=80=98aud=E2=80=99 introspection response member)=

Token binding solves par= t of the resource constrained access token requirement, but does not solve = how the client authenticates to the AS.=C2=A0

=C2= =A0

-DW

On Jun 12, 2018, at 1:28 PM, Dick Har= dt <dick.hardt= @gmail.com> wrote:

H= ey OAuth WG

I have worked with Nat and Brian to merge ou= r concepts and those are captured in the updated draft.


We are hopeful the= WG will adopt this draft as a WG document.

Any co= mments and feedback are welcome!

/Dick
=
_______________________________________________
OAuth mailing list<= br>OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth


--000000000000fb41d205715a599a--