Inline... Phil
> On Feb 18, 2016, at 22:19, Nat Sakimura <[email protected]> wrote: > > Thanks for the explanation. Let me re-formulate. > > Assumption > 1. There are resource server – authorization server pairs: R1A1 … RnAn. > 2. There are clients C1 … Cm. > 3. These instances can be hosted on a multi-tenancy environment. > > Flow Step 0. The client discovers the resource server endpoint and its configs. Question: should that include oauth?? John seems to imply yes. > 1. Client Cx goes to a resource server Ry, but he was denied of the > access and was told to get an access token. Now Cx needs to know where to go. > 2. Cx uses << Discovery>> to find the OAuth endpoints and the associated > metadata on Ay that corresponds to Ry. Where is the discovery for Ay? > 3. Cx goes and fetches the Discovery file. > 4. Cx goes to Ay to get authorized using the config info in the Discovery > file and the rest is normal RFC6749. Referring to the risk that a client discovered from a bad source (eg to insert a fake token endpoint), how does Ay know what discovery the client used was correct? This might not be a problem in reality but it needs to work. > > Is this correct? > > Nat > > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > > From: Phil Hunt (IDM) [mailto:[email protected]] > Sent: Friday, February 19, 2016 1:58 PM > To: Nat Sakimura > Cc: Mike Jones; [email protected] > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > No. Much simpler. > > A service provider has decided to have a separate oauth server for each web > 'property'. This could be because they were acquired separately and run > different infrastructures. Or the business structure keeps each BU completely > separate. > > The client can't really depend on previously known or hard coded endpoints > because there are 1000s of instances deployed (eg as in tenancies). > > This dynamic discovery is going to be particularly true of open source > software that customers choose to host on PaaS cloud providers of their > choosing. > > Phil > > On Feb 18, 2016, at 19:04, Nat Sakimura <[email protected]> wrote: > > Hi Phil, > > You wrote: > > If example.com had separate oauth servers for services xyz and abc, > > how would discovery work from a single /.well-known endpoint? > > I am trying to understand your use case, but I am not sure if I do. > > The use case seems to be such that: > > - There is a client C1. It could be a CRM or any kind of application > that uses RFC6749 and RFC6750 to access other resources a resource server R1. > C1 and R1 has a pre-configured relationship. > - The resource server R1 supports RFC6750, and can have multiple OAuth > RFC6749 endpoints that it supports, which are A1, …, An. > - Ax supports multiple resource services, Rx. > - There is a user U1 that wants to access C1, which in turn access R1. > U1 gets authenticated somehow at C1. It could be either through a password > system at C1, or through a federated login protocol supported at Ax, such as > OpenID Connect. > > Another possibility is a case where Cx = Rx, which makes things a bit simpler. > > Is this what you have in mind? Please let me know. If it is not, please > correct me. > > Cheers, > > Nat > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > > From: OAuth [mailto:[email protected]] On Behalf Of Phil Hunt (IDM) > Sent: Friday, February 19, 2016 2:09 AM > To: Mike Jones > Cc: [email protected] > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > How does the client request the oauth configuration assigned to xyz? > > The example you give appears to presume a single oauth infrastructure for all > apps. > > The only way right now to have apps specific oauth is to infer the relation > by the domain "xyz.example.com". > > That makes discovery more complex because there arw many more discovery > locations and many more configurations to maintain. > > If example.com had separate oauth servers for services xyz and abc, how would > discovery work from a single /.well-know endpoint? > > Phil > > On Feb 18, 2016, at 09:41, Mike Jones <[email protected]> wrote: > > Let me second John’s point that OAuth configuration information and > application configuration information need not be interspersed. For > instance, if the service is at https://example.com and the XYZ application is > being used, then these configuration metadata documents could both be used: > · https://example.com/.well-known/openid-configuration - OAuth > configuration metadata > · https://example.com/.well-known/xyz-configuration - XYZ configuration > metadata > > There’s not much point in defining a new /.well-known/oauth2.0 value, since > there is no such thing as generic OAuth 2.0. By definition, it must always > be used in an application context that profiles OAuth 2.0 to enable > interoperability. The existing /.well-known/openid-configuration value works > fine for this purpose. Yes, the optics of having a different value might > seem better but it comes at the cost of interoperability problems. In my > view, interop trumps optics. > > To a point that George Fletcher made, WebFinger could still be used to learn > the locations of these configuration metadata documents if that makes sense > in the application context. The editors took WebFinger out of the OAuth > Discovery document since it isn’t always applicable. > > Cheers, > -- Mike > > From: John Bradley [mailto:[email protected]] > Sent: Thursday, February 18, 2016 7:41 AM > To: Phil Hunt <[email protected]> > Cc: Mike Jones <[email protected]>; [email protected] > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > I suspect that the configuration well-knowns are going to be on the root > domain. You could try and get a user to put in crm.example.com, but I > suspect that is not going to work. > > If the app doesn’t have a specific protocol identifier then it would use the > default. > > I don’t know if you can get around having some sort of app/protocol > identifier configured in the app. > > John B. > > > > > > > On Feb 18, 2016, at 9:49 AM, Phil Hunt <[email protected]> wrote: > > resource service X could be any http accessible service: > > * CRM > * Finance > * Payroll > * ERP > * any application on the web. > > The spec seems to suggest that we use /.well-known/crm to discover OAuth > config for crm. But that may cause conflict if crm has its own discovery. > Which leads us down the path of doing something like “crm-oauth”. > > Then there is confusion about what host the discovery is done on. > > For example, hypothetically do I do: > > GET /.well-known/crm > Host: example.com > > But what about the CRM’s configuration information. Is this stomping on it? > > Or, what If we put the oauth configuration at the host for the crm service: > GET /.well-known/openid-configuration > Host: crm.example.com > > I think the point is that there is a relationship between a protected > resource and its designated OAuth service. > > The client needs to discover: > * Where is its designated resource service and what security does it use > * If it is OAuth, where is the intended OAuth configuration for that resource > service instance? > > Phil > > @independentid > www.independentid.com > [email protected] > > > > > > On Feb 18, 2016, at 7:19 AM, John Bradley <[email protected]> wrote: > > Can you clarify what you mean by “resource service x”? > > Is that the RS base URI for the resource, a specific URI that the client is > requesting? > > That is getting UMA ish. > > The concept of a base RS URI is a rat hole that I prefer not to go down, as > it is something everyone thinks exists but like SCIM if it exists it is > protocol or deployment specific. > > The notion that you would send the URI you are planning on requesting to a > Webfinger server to find the OAuth server, is probably going to have privacy > issues. > > I suspect that you need to hand back a error from the resource to say where > the AS is, or have a .well-known for the RS. > > RS discovery probably wants to be separate from AS discovery. (Yes I do > think we need something, UMA rpt or something like it might be a way to go) > > John B. > > On Feb 18, 2016, at 9:06 AM, Phil Hunt <[email protected]> wrote: > > Maybe SCIM was a bad example. It functions as a RESTful resource in the > context of OAuth. > > I find the use of OIDC to be confusing as an example (and the default) > because it is both an OAuth resource and a security service. It is a > modification of OAuth. > > Start thinking about every application ever written that uses OAuth. Are we > expecting 100s of thousands of these to each register? > > To me, this specification is a fine specification for OIDC and it should be > published there because the specification defines how to discovery OAuth and > OpenID information. > > Likewise you suggest it is ok for SCIM to do the same. > > How do we expect normal applications to set up and do discovery? > > It seems to me that an “OAUTH” discovery spec should have a parameter to ask, > I want to discover OAuth configuration for resource service X. > > That still allows me to have a separate discovery service that says, tell me > about resource service X itself. > > BTW. I think we are FAR from Last Call on this topic. > > Phil > > @independentid > www.independentid.com > [email protected] > > > > > > On Feb 18, 2016, at 6:55 AM, John Bradley <[email protected]> wrote: > > Diffrent protocols like Connect and SCIM may have different configurations, > endpoints , keys , authentication methods, scopes etc. > > It should be posable to have them as one document, but forcing them to use > one document is going to cause a explosion of claim registration for > discovery. > > I think it is better for SCIM to register one well known than to have to > register 20 claims with scim prefixes or something silly like that. > > Name-spacing the claims by allowing them to be in different well known files > is not unreasonable. > > Remember some of these protocols may be hosted on SaaS so there is no > guarantee that all protocols will have the same OAuth Config. > > Nothing stops a protocol from doing what it likes with webfinger if it wants > to use that for discovery. > > In principal I like the idea of having another protocol as an example. > > My only concern is that I haven’t seen any discussion of your SCIM discovery > document in the SCIM WG. > I personally think sorting out discovery for SCIM is a good idea, but OAUTh > is but one of several authentication methods for SCIM, and there are probably > other non OAuth things that want to be described. > > I would feel better about using it as an example if it were adopted by the WG > and some general interest shown. > > I encourage you to do that so we can use it as a example. > > John B. > > On Feb 18, 2016, at 8:35 AM, Phil Hunt <[email protected]> wrote: > > I still find the following text objectionable and confusing… > By default, for historical reasons, unless an application-specific > well-known URI path suffix is registered and used for an application, > the client for that application SHOULD use the well-known URI path > suffix "openid-configuration" and publish the metadata document at > the path formed by concatenating "/.well-known/openid-configuration" > to the authorization server's issuer identifier. As described in > Section 5, despite the identifier > "/.well-known/openid-configuration", appearing to be OpenID-specific, > its usage in this specification is actually referring to a general > OAuth 2.0 feature that is not specific to OpenID Connect. > > Further, as a default “openid-configuration” as the default further gives > people the impression that a plain OAuth server *is* an authentication server > and that the normal access token received is evidence of a successful > authentication. > > It would be better to point out that application may include oauth discovery > in their discovery URI and that OAuth is an example of this. It might be good > to include two examples. E.g. OIDC and SCIM (as another referenceable > example). > > GET /.well-known/openid-configuration > and > GET /.well-known/scim > Retrieve the OAuth configuration for the application openid and scim > respectively. > > The use of: > GET /.well-known/oauth2/ > Should be the default used when there is no known application based > well-known application based URI discovery. > > Of course, the concern I raised earlier is that this approach of application > specific URIs ends up requiring every application to make an IANA > registration if they don’t want to use the default of “oauth2” (or > “openid-configuration”). Is that what the authors expect? > > It seemed better to me to use the webfinger syntax to allow the client to say > “I want the designated OAuth configuration for the resource service X” would > be a better design that avoids extensive IANA registration. > > Phil > > @independentid > www.independentid.com > [email protected] > > > > > > On Feb 17, 2016, at 11:48 PM, Mike Jones <[email protected]> wrote: > > In response to working group input, this version of the OAuth Discovery > specification has been pared down to its essence – leaving only the features > that are already widely deployed. Specifically, all that remains is the > definition of the authorization server discovery metadata document and the > metadata values used in it. The WebFinger discovery logic has been removed. > The relationship between the issuer identifier URL and the well-known URI > path relative to it at which the discovery metadata document is located has > also been clarified. > > Given that this now describes only features that are in widespread > deployment, the editors believe that this version is ready for working group > last call. > > The specification is available at: > · http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 > > An HTML-formatted version is also available at: > · http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html > > -- Mike & Nat & John > > P.S. This notice was also posted at http://self-issued.info/?p=1544 and as > @selfissued. > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
