There is also existing software that expects to be able to act/respond based only on the WWW-Authenticate header. See
https://hc.apache.org/httpcomponents-client-4.5.x/httpclient/apidocs/org/apache/http/auth/AuthScheme.html#processChallenge(org.apache.http.Header) <https://hc.apache.org/httpcomponents-client-4.5.x/httpclient/apidocs/org/apache/http/auth/AuthScheme.html#processChallenge(org.apache.http.Header)> -DW > On Jul 20, 2018, at 2:33 AM, n-sakimura <n-sakim...@nri.co.jp> wrote: > > Hi David, > > Thanks for the comment, and sorry for the delay in my reply. > > Doing it with Web Linking [RFC8288] has several advantages. > > It is standard based J It is just a matter of registering link relations to > the IANA Link Relation Type Registry, and it is quite widely used. > No or very little coding needed: Other than adding some HTTP server > configuration, the rest stays the same as RFC6750. > Standard interface: this kind of metadata is applicable not only for letting > the client find the appropriate authorization server but for other metadata > as well. Also, other endpoints as long as it is supporting the direct > communication with the client, can provide relevant metadata with it without > going through the client authorization. > > I did not quite follow why CORS is relevant here. We are just talking about > the client to server communication, and there are no embedded resources in > the response. Could you kindly elaborate a little, please? > > For the second point, since it was discussed in the WG meeting yesterday, I > will defer to that discussion. > > Best, > > Nat Sakimura > > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of David Waite > Sent: Thursday, July 19, 2018 4:55 PM > To: Dick Hardt <dick.ha...@gmail.com> > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] updated Distributed OAuth ID > > 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="example_realm", > scope="example_scope", > error=“invalid_token", > resource_uri="https://api.example.com/resource > <https://api.example.com/resource>", > > oauth_server_metadata_uris="https://as.example.com/.well-known/oauth-authorization-server > <https://as.example.com/.well-known/oauth-authorization-server> > https://different-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 CORS > policy, and can’t be limited by the kind of link. > > Second: (retaining link format) Is there a reason the metadata location is > specified the way it is? It seems like > > <https://as.example.com/.well-known/oauth-authorization-server > <https://as.example.com/.well-known/oauth-authorization-server>>; > rel=“oauth_server_metadata_uri" > > should be > > <https://as.example.com <https://as.example.com/>>; rel=“oauth_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 their > extensions to attempt to resolve, treating ‘regular’ OAuth as a fallback. > 3. Define their own parameter, such as rel=“specialauth_issuer”, 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. > > Third: I have doubts of the usefulness of resource_uri in parallel to both > the client requested URI and the Authorization “realm” parameter. > > 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 “resource URI” is also confusing, as I would expect 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 “An OAuth 2.0 Resource Endpoint specified > in [RFC6750] section 3.2 - where the term doesn’t appear 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). > 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 “ realm” parameter? > 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’m 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). > > 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 including 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 “scope”) would also be applied to this request. > > Normal authorization grant flow would then happen (as this is the only grant > type supported by RFC6750). Once the access token is acquired by the client, > the client associates that token with the “realm” parameter given in the > initial challenge by the resource server origin. Likewise, the ‘aud’ 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. > > Fourth and finally: Is the intention to eventually recommend token binding > 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, ‘aud’ > introspection response member) > > -DW > > > On Jun 12, 2018, at 1:28 PM, Dick Hardt <dick.ha...@gmail.com > <mailto:dick.ha...@gmail.com>> 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/ > <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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
