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> 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";, > "token_endpoint": "https://server.example.com/token";, > "token_endpoint_auth_methods_supported": ["client_secret_basic", > "private_key_jwt"], > "registration_endpoint": "https://server.example.com/register";, > "response_types_supported": ["code", "token"], > "service_documentation": > "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] > Sent: Wednesday, February 24, 2016 12:45 PM > To: Anthony Nadalin <tony...@microsoft.com> > Cc: Mike Jones <michael.jo...@microsoft.com>; <oauth@ietf.org> > <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> 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> > Cc: <oauth@ietf.org> <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>; Phil Hunt (IDM) > <phil.h...@oracle.com>; Nat Sakimura <sakim...@gmail.com> > Cc: <oauth@ietf.org> <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] On Behalf Of Mike Jones > Sent: Wednesday, February 24, 2016 9:54 AM > To: Phil Hunt (IDM) <phil.h...@oracle.com>; Nat Sakimura <sakim...@gmail.com> > Cc: <oauth@ietf.org> <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] On Behalf Of Phil Hunt (IDM) > Sent: Wednesday, February 24, 2016 8:39 AM > To: Nat Sakimura <sakim...@gmail.com> > Cc: <oauth@ietf.org> <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> 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>: > 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 > phil.h...@oracle.com > > > > > > On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakim...@gmail.com> wrote: > > > Hi Thomas, > > inline: > > 2016年2月22日(月) 18:44 Thomas Broyer <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> 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 > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
