Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

2016年2月19日(金) 14:58 Phil Hunt (IDM) : > Inline... > > Phil > > On Feb 18, 2016, at 22:19, Nat Sakimura 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

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

Inline... Phil > On Feb 18, 2016, at 22:19, Nat Sakimura 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 mu

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

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 1. Client Cx goes to a resource ser

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 prev

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

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

[OAUTH-WG] " Help" unsubscribe

ing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > ------ next part -- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20160218/6d7b6e3b/attachment.html>

Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values

+1 to adopt. My previous concerns of this draft have been addressed, and I am supportive of having an IANA registry of amr values. On Thu, Feb 18, 2016 at 5:09 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > In response to my message to the list regarding the initial call for > adopt

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

Thanks, William. I’m good with referencing the registry in Section 2. I’ll think about the registered/public/private comment. It’s fine to reference oauth-mix-up-mitigation as a draft in a finished RFC as long as it’s an informative and not a normative reference.

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

I'm fine with changing dynamic registration from being RECOMMENDED to OPTIONAL. That's good actionable feedback. Likewise, looking at again, we also need to change jwks_uri from REQUIRED to OPTIONAL, since not all OAuth deployments need keys. I expect more good, actionable feedback to also co

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

We are establishing a registry. Some folks do use dynamic client registration. We can register it in this document or take it out and let others register it once the registry is established. It will be registered one way or the other. One of the reasons for starting last call is to get p

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

Not sure about that. There are things that are "recommended" like the dynamic registration endpoint, I don't understand why this is recommended as a lot of folks still don't do this. There are security considerations about all the information that is in the discovery that have not been addressed

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

It's the OAuth-specific subset of what's already widely deployed. Nothing was invented - just subsetted. I think it's already as simple as possible unless the working group decides to remove even more functionality (which it can obviously do). -- Mike -Orig

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

I also think we are way far from last call (and surprised to see last call issued) on this document as it is still very complex for something that should be very simple -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, February

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

The protocol would need to have a .well-known location registered or use the default well-known for OAuth. Apps would look for there specific configuration and fall back to the generic one if that is not available. To save apps making multiple request the server can just link the app specific

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

If there were different OAuth services, they would be located at different URLs, with different .well-known documents at those URLs. From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] Sent: Thursday, February 18, 2016 9:09 AM To: Mike Jones Cc: John Bradley ; oauth@ietf.org Subject: Re: [OAUTH-

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 com

Re: [OAUTH-WG] Initial OAuth working group Device Flow specification

I had previously made some comments on this back in November, but never heard any response. These were things I ran into while implementing the device flow on one of my servers. https://mailarchive.ietf.org/arch/msg/oauth/JzH-isRij9kCpbEJpXVqwZ6XjjU https://mailarchive.ietf.org/arch/msg/oauth/XQJ

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

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: ·

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 ge

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

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

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

On 02/18/2016 03:06 PM, Phil Hunt wrote: > BTW. I think we are FAR from Last Call on this topic. Thanks for your feedback, Phil. As you have seen I had issued a WGLC prior to your message based on the claim from the authors that they believe the document is finished. We will, of course, take al

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

Hi Phil, >From the RESTful perspective, it is the resource that should specify where the client should find the configuration etc. through RFC5988. As RFC5785 states, /.well-known/ uri is a last resort when this approach does not work, e.g., when you cannot access the resource before knowing the m

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

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

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

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

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

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 i

[OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Hi all, This is a Last Call for comments on the OAuth 2.0 Discovery specification: https://tools.ietf.org/html/draft-ietf-oauth-discovery-01 Since this document was only adopted recently we are running this last call for **3 weeks**. Please have your comments in no later than March 10th. Ciao

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

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-configu

[OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values

In response to my message to the list regarding the initial call for adoption of the Authentication Method Reference Values draft, see https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html, Mike submitted an updated version of the document to take raised concerns into account. Several w

[OAUTH-WG] Initial OAuth working group Device Flow specification

Thanks to William Denniss for creating the initial working group version of the OAuth 2.0 Device Flow specification. The abstract of the specification is: The device flow is suitable for OAuth 2.0 clients executing on devices which do not have an easy data-entry method (e.g., game consoles, TVs