Authorization server discovery. > On Feb 25, 2016, at 8:10 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > > Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your > suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 > Authorization Server Discovery”. While the abstract already makes it clear > that the scope of the document is AS discovery, doing so in the title seems > like it could help clarify things, given that a lot of the discussion seems > to be about resource discovery, which is out of scope of the document. > > I’m not saying that resource discovery isn’t important – it is – but unlike > authorization server discovery, where there’s lots of existing practice, > including using the existing data format for describing OAuth implementations > that aren’t being used with OpenID Connect, there’s no existing practice to > standardize for resource discovery. The time to create a standard for that > seems to be after existing practice has emerged. It *might* or might not use > new metadata values in the AS discovery document, but that’s still to be > determined. The one reason to leave the title as-is is that resource > discovery might end up involving extensions to this metadata format in some > cases. > > I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies. > 6749 is about the AS. 6750 is about the RS. The discovery document is > about the AS. We don’t yet have a specification or existing practice for RS > discovery, which would be the 6750 analogy. > > In summary, which title do people prefer? > · “OAuth 2.0 Discovery” > · “OAuth 2.0 Authorization Server Discovery” > > -- Mike > <> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov > Sent: Thursday, February 25, 2016 12:59 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > In OIDC the discovery doc is of great utility to developers and integrators. > Developers also tend to find it a more accurate and complete description of > how to set up a client for a particular deployment, compared to traditional > online docs, which may be not be up to date, or even missing. Very much like > auto-generated Swagger and JavaDocs. > > Here are some example OIDC discovery docs: > > https://accounts.google.com/.well-known/openid-configuration > <https://accounts.google.com/.well-known/openid-configuration> > > https://www.paypalobjects.com/.well-known/openid-configuration > <https://www.paypalobjects.com/.well-known/openid-configuration> > > https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration > > <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration> > > > With this discovery document in place setup of identity federation can then > be easily scripted. For example: > > http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html > > <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html> > > > Now, does that dictate any particular app architecture? My reading of the > spec is that it doesn't, and it shouldn't either. By staying neutral on the > topics of RS discovery and registering RPs with RSs. And how one arrives at > the ".well-known/...". I'm not even sure that resource discovery should be a > topic of this WG. Perhaps to this end, and to prevent confusion that the spec > is trying to do something more, a more specific title would suit it better. > E.g. "AS Discovery". > > Cheers, > > Vladimir > > > > > On 25/02/16 02:25, Phil Hunt (IDM) wrote: > And so does oracle and so does google. Each different. > > So how can an app dictate it then unless we all go to a common architecture? > > Phil > > On Feb 24, 2016, at 16:04, Mike Jones <michael.jo...@microsoft.com> > <mailto:michael.jo...@microsoft.com> wrote: > > Azure defines ways for resource servers to be registered for use with a > client and for clients to dynamically request an access token for use at a > particular resource server. You can call that custom architecture if you > want. It’s well-defined but it’s not currently in the standards realm. I > know that Google has syntax for doing the same, as I’m sure do a lot of other > cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working > group talked about possibly producing a standard version of syntax for making > these kinds of requests during our discussions in Prague (during the Token > Exchange discussion) but nobody has run with this yet. > > In this sense, yes, Azure is an application of the kind we’re talking about. > Azure already does define specific new OAuth 2.0 discovery metadata values > that are used in production. A registry just doesn’t yet exist in which it > can register those that are of general applicability. > > -- Mike > > From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com > <mailto:phil.h...@oracle.com>] > Sent: Wednesday, February 24, 2016 3:52 PM > To: Mike Jones > Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > Mike > > Take a look at the assumptions you are making. > > You seem to be assuming application software dictates oauth infrastructure > architecture by suggesting that apps register in iana. > > Would ms azure allow custom arch? > > Phil > > On Feb 24, 2016, at 15:28, Mike Jones <michael.jo...@microsoft.com> > <mailto:michael.jo...@microsoft.com> wrote: > > The UserInfo Endpoint path isn’t fixed and so has to be discovered. > > I agree that for some OAuth profiles, one or more resource servers will have > to be discovered starting from the authorization server. Working group > members have also described wanting to discover authorization servers > starting from resource servers. There isn’t a standard practice for any of > this, which is why it’s intentionally left out of the current specification. > > Once the IANA OAuth Discovery Metadata Registry has been established, which > will happen after the current specification has been approved, it will be > easy for subsequent specifications to document existing practice for > different OAuth profiles and register discovery metadata values supporting > them. Some of those values will likely define ways to discover resource > servers, when applicable. > > But first, we need to finish the existing spec, so that the registry enabling > these extensions gets established in the first place. > > -- Mike > > From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com > <mailto:phil.h...@oracle.com>] > Sent: Wednesday, February 24, 2016 2:13 PM > To: Mike Jones <michael.jo...@microsoft.com> > <mailto:michael.jo...@microsoft.com> > Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> > <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > Yup. And because there many relations the client mist be able to discover it. > The client does not know if the res server is legit. > > The userinfo is always fix and so u dont need discovery. > > Phil > > On Feb 24, 2016, at 14:05, Mike Jones <michael.jo...@microsoft.com> > <mailto:michael.jo...@microsoft.com> wrote: > > In OpenID Connect, there’s a resource server called the UserInfo Endpoint > that returns claims about the authenticated user as a JSON data structure. > Its location is published in OpenID Connect discovery metadata as the > “userinfo_endpoint” metadata value, which is defined at > http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata > <http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata>. > > We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec > since in OAuth, there are lots of possible relationships between > authorization servers and resource servers and they needn’t be one-to-one, as > is being actively discussed by the working group. For instance, see George > Fletcher’s recent contribution. > > Thanks for the good discussion, Phil. > > -- Mike > > From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com > <mailto:phil.h...@oracle.com>] > Sent: Wednesday, February 24, 2016 1:25 PM > To: Mike Jones > Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > Where is the profile endpoint (oidc's resource server) published? (For the > non OIDC people on the list). > > Phil > > On Feb 24, 2016, at 13:09, Mike Jones <michael.jo...@microsoft.com> > <mailto:michael.jo...@microsoft.com> wrote: > > To the extent that generic OAuth 2.0 needs to publish some of the same > information as OpenID Connect – which is built on generic OAuth 2.0 – it > makes sense to publish that information using exactly the same syntax, since > that syntax is already in widespread use. That what this draft accomplishes. > > There’s nothing Connect-specific about using metadata response values like: > > "authorization_endpoint": "https://server.example.com/authorize"; > <https://server.example.com/authorize>, > "token_endpoint": "https://server.example.com/token"; > <https://server.example.com/token>, > "token_endpoint_auth_methods_supported": ["client_secret_basic", > "private_key_jwt"], > "registration_endpoint": "https://server.example.com/register"; > <https://server.example.com/register>, > "response_types_supported": ["code", "token"], > "service_documentation": > "http://server.example.com/service_documentation.html"; > <http://server.example.com/service_documentation.html>, > > Is there a reason that you would like the syntax for any of these or the > other generally applicable OAuth 2.0 metadata values to be different? I > don’t see any good reason for unnecessary differences to be introduced. > > -- Mike > > From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com > <mailto:phil.h...@oracle.com>] > Sent: Wednesday, February 24, 2016 12:45 PM > To: Anthony Nadalin <tony...@microsoft.com> <mailto:tony...@microsoft.com> > Cc: Mike Jones <michael.jo...@microsoft.com> > <mailto:michael.jo...@microsoft.com>; <oauth@ietf.org> > <mailto:oauth@ietf.org> <oauth@ietf.org> <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > Mike > > Publishing on dev pages does not work for software (esp open source) that is > deployed both in enterprises and on PaaS cloud providers. > > The current draft is may codify current OIDC practice and be appropriate for > oidc but it is not ready for generic oauth. There is no generic oauth > experience at this time. > > Phil > > On Feb 24, 2016, at 10:25, Anthony Nadalin <tony...@microsoft.com> > <mailto:tony...@microsoft.com> wrote: > > Sure there is, it is as you have now made it far easier and the security > considerations does not even address this > > From: Mike Jones > Sent: Wednesday, February 24, 2016 10:22 AM > To: Anthony Nadalin <tony...@microsoft.com> <mailto:tony...@microsoft.com> > Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> > <mailto:oauth@ietf.org> > Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location > > As we’d discussed in person, there’s no effective security difference between > discovery information being published in an ad-hoc fashion on developer pages > and it being published in a standard format. “Security by obscurity” adds no > real security at all. > > -- Mike > > From: Anthony Nadalin > Sent: Wednesday, February 24, 2016 10:01 AM > To: Mike Jones <michael.jo...@microsoft.com> > <mailto:michael.jo...@microsoft.com>; Phil Hunt (IDM) <phil.h...@oracle.com> > <mailto:phil.h...@oracle.com>; Nat Sakimura <sakim...@gmail.com> > <mailto:sakim...@gmail.com> > Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> > <mailto:oauth@ietf.org> > Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location > > The point of the WGLC is to finish standardizing the core discovery > functionality that’s already widely deployed. > > That may be widely deployed for OIDC but not widely deployed for OAuth. There > are some authentication mechanism discovery for endpoint that really should > not be in an OAuth standard since it’s really not dealt with. Now that all > this information is available it makes poking around the endpoint more > focused for people that want to disrupt your endpoints, that is really not > addressed in the security considerations section at all > > From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] > On Behalf Of Mike Jones > Sent: Wednesday, February 24, 2016 9:54 AM > To: Phil Hunt (IDM) <phil.h...@oracle.com> <mailto:phil.h...@oracle.com>; Nat > Sakimura <sakim...@gmail.com> <mailto:sakim...@gmail.com> > Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> > <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > The point of the WGLC is to finish standardizing the core discovery > functionality that’s already widely deployed. > > None of Nat or John or I are suggesting that additional related functionality > won’t be created. I’m sure it will be. Some applications will use WebFinger > to locate the discovery metadata. Some will possibly use link headers. Some > will possibly use application-specific .well-known values. I’m sure there’s > other things I haven’t even thought about. All of these depend upon having a > discovery metadata document format and none of them change it – other than > possibly to register additional discovery metadata values. > > So by all means, the working group should continue discussing inventing > possible new related mechanisms that make sense in some contexts. At the > same time, we can finish standardizing the already widely deployed core > functionality that all of these mechanisms will need. > > -- Mike > > From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] > On Behalf Of Phil Hunt (IDM) > Sent: Wednesday, February 24, 2016 8:39 AM > To: Nat Sakimura <sakim...@gmail.com> <mailto:sakim...@gmail.com> > Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> > <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > I am suggesting that part of the discovery solution has to be the client > indicating what resource endpoint it wants the oauth configuration data for. > > So if res.example.evil.com is not a valid resource endpoint for > as.example.com the authz discovery should fail in some way (eg return > nothing). > > There may be better ways to do this. Eg combine discovery. Or change the > order of discovery. > > One of OAuth's strength's and weaknesses is that the target of authorization > (the resource) is never specified. It is often bound up in the client > registration and an often implied 1:1 relationship between resource and as. > Given that in discovery phase registration has not yet occurred it seems > important that the client know it has a valid combination of endpoints etc. > > This is why I was disappointed about wglc on discovery. We had a starting > point for group adoption but we haven't really defined the full requirements > IMO. > > I am on vacation or I would put some thought into some draft changes or a new > draft. I apologize I can't do it now. > > Phil > > On Feb 24, 2016, at 08:12, Nat Sakimura <sakim...@gmail.com> > <mailto:sakim...@gmail.com> wrote: > > Hi Phil, > > Are you suggesting that the AS metadata should include the RS URIs? > Currently, it does not, but it can be done, I guess. > > The way oauth-meta works is that > > 1. RS tells the client where the AS is. > 2. AS tells the client which RS endpoints the token can be used. > > Even if there is a bad AS with a valid certs that proxies to the good RS, the > client will not send the token there as the authz server will say that is not > the place the client may want to send the token to. > > Nat > > 2016年2月24日(水) 23:59 Phil Hunt <phil.h...@oracle.com> > <mailto:phil.h...@oracle.com>: > Nat, > > I’m not sure that having the resource server tell the client where its > authorization server is secure by itself. The relationship between the > Authorization Server and the Resource server need to be bound together in one > of the discovery endpoints (the resource and/or the oauth service discovery). > > If a client discovers a fake resource server that is proxying for a real > resource server the current discovery spec will not lead the client to > understand it has the wrong resource server. Rather the fake resource service > will just have a fake discovery service. The hacker can now intercept > resource payload as well as tokens because they were able to convince the > client to use the legit authorization service but use the token against the > hackers proxy. > > The OAuth Discovery service needs to confirm to the client that the server is > able to issue tokens for a stated resource endpoint. > > This not only works in normal OAuth but should add security even to UMA > situations. > > Phil > > @independentid > www.independentid.com <http://www.independentid.com/> > phil.h...@oracle.com <mailto:phil.h...@oracle.com> > > > > > > On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakim...@gmail.com> > <mailto:sakim...@gmail.com> wrote: > > > Hi Thomas, > > inline: > > 2016年2月22日(月) 18:44 Thomas Broyer <t.bro...@gmail.com> > <mailto:t.bro...@gmail.com>: > Couldn't the document only describe the metadata? > I quite like the idea of draft-sakimura-oauth-meta if you really want to do > discovery, and leave it open to implementers / to other specs to define a > .well-known URL for "auto-configuration". > The metadata described here would then either be used as-is, at any URL, > returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for > other metadata specs (like OpenID Connect). > With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of > WWW-Authenticate response header, you have everything you need to proceed > > Yup. That's one of the requirements to be RESTful, is it not? > > In OAuth's case, the resource and the authorization server are usually > tightly coupled. (Otherwise, you need another specs like UMA.) > So, the resource server should be able to tell either the location of the > authz endpoint. In some trusted environment, the resource may as well return > the location of the authz server configuration data. In these cases, you do > not have to decide on what .well-known uri as you say. This frees up > developers from configuration file location collisions etc. We should strive > not to pollute the uri space as much as possible. > > (well, except if there are several ASs each with different scopes; sounds > like an edge-case to me though; maybe RFC6750 should instead be updated with > such a parameter such that an RS could return several WWW-Authenticate: > Bearer, each with its own "scope" and "duri" value?) > > Yeah, I guess it is an edge case. I would rather like to see these authz > servers to develop a trust framework under which they can agree on a single > set of common scope parameter values. > > Cheers, > > Nat > > > > On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <jric...@mit.edu> > <mailto:jric...@mit.edu> wrote: > The newly-trimmed OAuth Discovery document is helpful and moving in the right > direction. It does, however, still have too many vestiges of its OpenID > Connect origins. One issue in particular still really bothers me: the use of > “/.well-known/openid-configuration” in the discovery portion. Is this an > OAuth discovery document, or an OpenID Connect one? There is absolutely no > compelling reason to tie the URL to the OIDC discovery mechanism. > > I propose that we use “/.well-known/oauth-authorization-server” as the > default discovery location, and state that the document MAY also be reachable > from “/.well-known/openid-configuration” if the server also provides OpenID > Connect on the same domain. Other applications SHOULD use the same parameter > names to describe OAuth endpoints and functions inside their service-specific > discovery document. > > — Justin > _______________________________________________ > 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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > 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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > -- > Vladimir Dzhuvinov :: vladi...@connect2id.com > <mailto:vladi...@connect2id.com>_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
