+1 Sent by MailWise – See your emails as clean, short chats.
-------- Originalnachricht -------- Betreff: Re: [OAUTH-WG] OAuth 2.0 Discovery Location Von: Justin Richer <jric...@mit.edu> An: George Fletcher <gffle...@aol.com> Cc: "<oauth@ietf.org>" <oauth@ietf.org> >+1 for “OAuth 2.0 Authorization Server Discovery” > > — Justin > >> On Feb 25, 2016, at 2:20 PM, George Fletcher <gffle...@aol.com> wrote: >> >> +1 for “OAuth 2.0 Authorization Server Discovery” >> >> On 2/25/16 2:10 PM, Mike Jones 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 <mailto:oauth-boun...@ietf.org>] >>> On Behalf Of Vladimir Dzhuvinov >>> Sent: Thursday, February 25, 2016 12:59 AM >>> To: oauth@ietf.org <mailto: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 <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 > > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
