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

Reply via email to