Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AB01AD0D2 for ; Thu, 18 Feb 2016 21:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpRqwd3YIb8r for ; Thu, 18 Feb 2016 21:19:29 -0800 (PST) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42E61AD16B for ; Thu, 18 Feb 2016 21:19:28 -0800 (PST) Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs02.index.or.jp (Postfix) with SMTP id 1AD1D196878; Fri, 19 Feb 2016 14:19:28 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp (unknown) with ESMTP id u1J5JRTp019910; Fri, 19 Feb 2016 14:19:27 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u1J5JRWa050511; Fri, 19 Feb 2016 14:19:27 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u1J5JRiN050506; Fri, 19 Feb 2016 14:19:27 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u1J5JRUT050503; Fri, 19 Feb 2016 14:19:27 +0900 From: "Nat Sakimura" To: "'Phil Hunt \(IDM\)'" References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> <01f301d16ab9$eb8a04c0$c29e0e40$@nri.co.jp> <9C09EE5B-CB1C-4DDE-8F5B-3CBF49BB3C85@oracle.com> In-Reply-To: <9C09EE5B-CB1C-4DDE-8F5B-3CBF49BB3C85@oracle.com> Date: Fri, 19 Feb 2016 14:19:33 +0900 Message-ID: <023e01d16ad5$1defad00$59cf0700$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023F_01D16B20.8DDE80F0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGS4qFsTGL4fIzuwSUDfPQF/59lfwFfZWRKAXSIQK8DFjyYOQKDVIVZAUNy/HEBYalTWQDkn8zeAONwRlEB+5pRSQFnm5sxny3y5TA= Content-Language: ja x-mailadviser: 20141126 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 05:19:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_023F_01D16B20.8DDE80F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks for the explanation. Let me re-formulate.=20 =20 Assumption 1. There are resource server =E2=80=93 authorization server pairs: = R1A1 =E2=80=A6 RnAn.=20 2. There are clients C1 =E2=80=A6 Cm.=20 3. These instances can be hosted on a multi-tenancy environment.=20 =20 Flow 1. Client Cx goes to a resource server Ry, but he was denied of the = access and was told to get an access token. Now Cx needs to know where = to go.=20 2. Cx uses << Discovery>> to find the OAuth endpoints and the = associated metadata on Ay that corresponds to Ry.=20 3. Cx goes and fetches the Discovery file.=20 4. Cx goes to Ay to get authorized using the config info in the = Discovery file and the rest is normal RFC6749.=20 =20 Is this correct?=20 =20 Nat =20 -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. =20 From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20 Sent: Friday, February 19, 2016 1:58 PM To: Nat Sakimura Cc: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence =20 No. Much simpler.=20 =20 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.=20 =20 The client can't really depend on previously known or hard coded = endpoints because there are 1000s of instances deployed (eg as in = tenancies).=20 =20 This dynamic discovery is going to be particularly true of open source = software that customers choose to host on PaaS cloud providers of their = choosing.=20 Phil On Feb 18, 2016, at 19:04, Nat Sakimura > wrote: Hi Phil,=20 =20 You wrote:=20 > If example.com had separate oauth servers for = services xyz and abc,=20 > how would discovery work from a single /.well-known endpoint? =20 I am trying to understand your use case, but I am not sure if I do.=20 =20 The use case seems to be such that:=20 =20 - There is a client C1. It could be a CRM or any kind of = application that uses RFC6749 and RFC6750 to access other resources a = resource server R1. C1 and R1 has a pre-configured relationship.=20 - The resource server R1 supports RFC6750, and can have multiple = OAuth RFC6749 endpoints that it supports, which are A1, =E2=80=A6, An.=20 - Ax supports multiple resource services, Rx.=20 - There is a user U1 that wants to access C1, which in turn access = R1. U1 gets authenticated somehow at C1. It could be either through a = password system at C1, or through a federated login protocol supported = at Ax, such as OpenID Connect.=20 =20 Another possibility is a case where Cx =3D Rx, which makes things a bit = simpler.=20 =20 Is this what you have in mind? Please let me know. If it is not, please = correct me. =20 Cheers,=20 =20 Nat -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. =20 From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM) Sent: Friday, February 19, 2016 2:09 AM To: Mike Jones Cc: oauth@ietf.org =20 Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence =20 How does the client request the oauth configuration assigned to xyz? =20 The example you give appears to presume a single oauth infrastructure = for all apps.=20 =20 The only way right now to have apps specific oauth is to infer the = relation by the domain "xyz.example.com ". =20 =20 That makes discovery more complex because there arw many more discovery = locations and many more configurations to maintain.=20 =20 If example.com had separate oauth servers for = services xyz and abc, how would discovery work from a single /.well-know = endpoint? Phil On Feb 18, 2016, at 09:41, Mike Jones > wrote: Let me second John=E2=80=99s 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: * https://example.com/.well-known/openid-configuration - OAuth = configuration metadata * https://example.com/.well-known/xyz-configuration - XYZ = configuration metadata =20 There=E2=80=99s not much point in defining a new /.well-known/oauth2.0 = value, since there is no such thing as generic OAuth 2.0. By = definition, it must always be used in an application context that = profiles OAuth 2.0 to enable interoperability. The existing = /.well-known/openid-configuration value works fine for this purpose. = Yes, the optics of having a different value might seem better but it = comes at the cost of interoperability problems. In my view, interop = trumps optics. =20 To a point that George Fletcher made, WebFinger could still be used to = learn the locations of these configuration metadata documents if that = makes sense in the application context. The editors took WebFinger out = of the OAuth Discovery document since it isn=E2=80=99t always = applicable. =20 Cheers, -- Mike =20 From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Thursday, February 18, 2016 7:41 AM To: Phil Hunt > Cc: Mike Jones >; oauth@ietf.org = =20 Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence =20 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. =20 If the app doesn=E2=80=99t have a specific protocol identifier then it = would use the default. =20 =20 I don=E2=80=99t know if you can get around having some sort of = app/protocol identifier configured in the app. =20 John B. =20 =20 =20 =20 =20 =20 On Feb 18, 2016, at 9:49 AM, Phil Hunt > wrote: =20 resource service X could be any http accessible service: =20 * CRM * Finance * Payroll * ERP * any application on the web. =20 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 of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D. =20 Then there is confusion about what host the discovery is done on. =20 For example, hypothetically do I do: =20 GET /.well-known/crm Host: example.com =20 =20 But what about the CRM=E2=80=99s configuration information. Is this = stomping on it? =20 Or, what If we put the oauth configuration at the host for the crm = service: GET /.well-known/openid-configuration Host: crm.example.com =20 =20 I think the point is that there is a relationship between a protected = resource and its designated OAuth service.=20 =20 The client needs to discover: * Where is its designated resource service and what security does it use * If it is OAuth, where is the intended OAuth configuration for that = resource service instance? =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 18, 2016, at 7:19 AM, John Bradley > wrote: =20 Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? =20 Is that the RS base URI for the resource, a specific URI that the = client is requesting? =20 That is getting UMA ish.=20 =20 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 SCIM if it exists it = is protocol or deployment specific. =20 The notion that you would send the URI you are planning on requesting to = a Webfinger server to find the OAuth server, is probably going to have = privacy issues. =20 I suspect that you need to hand back a error from the resource to say = where the AS is, or have a .well-known for the RS. =20 RS discovery probably wants to be separate from AS discovery. (Yes I do = think we need something, UMA rpt or something like it might be a way to = go) =20 John B. =20 On Feb 18, 2016, at 9:06 AM, Phil Hunt > wrote: =20 Maybe SCIM was a bad example. It functions as a RESTful resource in the = context of OAuth. =20 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. =20 Start thinking about every application ever written that uses OAuth. Are = we expecting 100s of thousands of these to each register? =20 To me, this specification is a fine specification for OIDC and it should = be published there because the specification defines how to discovery = OAuth and OpenID information. =20 Likewise you suggest it is ok for SCIM to do the same.=20 =20 How do we expect normal applications to set up and do discovery? =20 It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should = have a parameter to ask, I want to discover OAuth configuration for = resource service X. =20 That still allows me to have a separate discovery service that says, = tell me about resource service X itself. =20 BTW. I think we are FAR from Last Call on this topic. =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 18, 2016, at 6:55 AM, John Bradley > wrote: =20 Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes etc. =20 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. =20 I think it is better for SCIM to register one well known than to have to = register 20 claims with scim prefixes or something silly like that. =20 Name-spacing the claims by allowing them to be in different well known = files is not unreasonable. =20 Remember some of these protocols may be hosted on SaaS so there is no = guarantee that all protocols will have the same OAuth Config. =20 Nothing stops a protocol from doing what it likes with webfinger if it = wants to use that for discovery. =20 In principal I like the idea of having another protocol as an example. =20 My only concern is that I haven=E2=80=99t seen any discussion of your = SCIM discovery document in the SCIM WG. =20 I personally think sorting out discovery for SCIM is a good idea, but = OAUTh is but one of several authentication methods for SCIM, and there = are probably other non OAuth things that want to be described. =20 I would feel better about using it as an example if it were adopted by = the WG and some general interest shown. =20 I encourage you to do that so we can use it as a example. =20 John B. =20 On Feb 18, 2016, at 8:35 AM, Phil Hunt > wrote: =20 I still find the following text objectionable and confusing=E2=80=A6 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-configuration" and publish the metadata document at the path formed by concatenating "/.well-known/openid-configuration" to the authorization server's issuer identifier. As described in Section 5 = , = despite the identifier "/.well-known/openid-configuration", appearing to be OpenID-specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect. =20 Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the = default further gives people the impression that a plain OAuth server = *is* an authentication server and that the normal access token received = is evidence of a successful authentication. =20 It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). =20 GET /.well-known/openid-configuration and GET /.well-known/scim Retrieve the OAuth configuration for the application openid and scim = respectively. =20 The use of: GET /.well-known/oauth2/ Should be the default used when there is no known application based = well-known application based URI discovery. =20 Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? =20 It seemed better to me to use the webfinger syntax to allow the client = to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 17, 2016, at 11:48 PM, Mike Jones > wrote: =20 In response to working group input, this version of the OAuth Discovery = specification has been pared down to its essence =E2=80=93 leaving only = the features that are already widely deployed. Specifically, all that = remains is the definition of the authorization server discovery metadata = document and the metadata values used in it. The WebFinger discovery = logic has been removed. The relationship between the issuer identifier = URL and the well-known URI path relative to it at which the discovery = metadata document is located has also been clarified. =20 Given that this now describes only features that are in widespread = deployment, the editors believe that this version is ready for working = group last call. =20 The specification is available at: * = http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 =20 An HTML-formatted version is also available at: * = = http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html =20 -- Mike & Nat = & John =20 P.S. This notice was also posted at = http://self-issued.info/?p=3D1544 = and as @selfissued. _______________________________________________ OAuth mailing list OAuth@ietf.org = https://www.ietf.org/mailman/listinfo/oauth =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 =20 =20 ------=_NextPart_000_023F_01D16B20.8DDE80F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

T= hanks for the explanation. Let me re-formulate. =

<= o:p> 

A= ssumption

<= span style=3D'mso-list:Ignore'>1.     T= here are resource server =E2=80=93 authorization server pairs: R1A1 = =E2=80=A6 RnAn.

<= span style=3D'mso-list:Ignore'>2.     T= here are clients C1 =E2=80=A6 Cm.

<= span style=3D'mso-list:Ignore'>3.     T= hese instances can be hosted on a multi-tenancy environment. =

<= o:p> 

F= low

<= span style=3D'mso-list:Ignore'>1.     C= lient Cx goes to a resource server Ry, but he was denied of the access = and was told to get an access token. Now Cx needs to know where to go. =

<= span style=3D'mso-list:Ignore'>2.     C= x uses << Discovery>> to find the OAuth endpoints and the = associated metadata on Ay that corresponds to Ry. =

<= span style=3D'mso-list:Ignore'>3.     C= x goes and fetches the Discovery file.

<= span style=3D'mso-list:Ignore'>4.     C= x goes to Ay to get authorized using the config info in the Discovery = file and the rest is normal RFC6749.

<= o:p> 

I= s this correct?

<= o:p> 

N= at

<= o:p> 

--=

PLEASE READ :This = e-mail is confidential and intended for the

named recipient = only. If you are not an intended recipient,

please notify the = sender=C2=A0 and delete this e-mail.

<= o:p> 

From:<= /b> Phil Hunt = (IDM) [mailto:phil.hunt@oracle.com]
Sent: Friday, February = 19, 2016 1:58 PM
To: Nat Sakimura
Cc: Mike Jones; = oauth@ietf.org
Subject: 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 previously known or hard coded endpoints = because there are 1000s of instances deployed (eg as in = tenancies). 

 

This = dynamic discovery is going to be particularly true of open source = software that customers choose to host on PaaS cloud providers of their = choosing. 


Phil


On Feb 18, 2016, at 19:04, Nat Sakimura <n-sakimura@nri.co.jp> = wrote:

H= i Phil,

&= nbsp;

Y= ou wrote:

&= gt; If example.com had separate oauth servers = for services xyz and abc,

> how would discovery work from = a single /.well-known endpoint?

&= nbsp;

I= am trying to understand your use case, but I am not sure if I do. =

&= nbsp;

T= he use case seems to be such that:

&= nbsp;

-       = T= here is a client C1. It could be a CRM or any kind of application that = uses RFC6749 and RFC6750 to access other resources a resource server R1. = C1 and R1 has a pre-configured relationship.

-       = T= he resource server R1 supports RFC6750, and can have multiple OAuth = RFC6749 endpoints that it supports, which are A1, =E2=80=A6, An. =

-       = A= x supports multiple resource services, Rx.

-       = T= here is a user U1 that wants to access C1, which in turn access R1. U1 = gets authenticated somehow at C1. It could be either through a password = system at C1, or through a federated login protocol supported at Ax, = such as OpenID Connect.

&= nbsp;

A= nother possibility is a case where Cx =3D Rx, which makes things a bit = simpler.

&= nbsp;

I= s this what you have in mind? Please let me know. If it is not, please = correct me.

&= nbsp;

C= heers,

&= nbsp;

N= at

--

PLEASE READ :This = e-mail is confidential and intended for the

named recipient = only. If you are not an intended recipient,

please notify the = sender  and delete this e-mail.

&= nbsp;

From:<= /b> OAuth [mailto:oauth-bounces@ietf.org]= On Behalf Of Phil Hunt (IDM)
Sent: Friday, February = 19, 2016 2:09 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: 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 complex because there arw many more discovery = locations and many more configurations to = maintain. 

 

If example.com had separate oauth servers = for services xyz and abc, how would discovery work from a single = /.well-know endpoint?


Phil


On Feb 18, 2016, at 09:41, Mike Jones <Michael.Jones@microsoft.com> wrote:

Let me second John=E2=80=99s 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:

=C2=B7       = https://exa= mple.com/.well-known/openid-configuration - OAuth configuration = metadata

=C2=B7       = https://exampl= e.com/.well-known/xyz-configuration - XYZ configuration = metadata

 

There=E2=80=99s not much point in defining a new /.well-known/oauth2.0 = value, since there is no such thing as generic OAuth 2.0.  By = definition, it must always be used in an application context that = profiles OAuth 2.0 to enable interoperability.  The existing = /.well-known/openid-configuration value works fine for this = purpose.  Yes, the optics of having a different value might seem = better but it comes at the cost of interoperability problems.  In = my view, interop trumps optics.

 

To a point that George Fletcher made, WebFinger could still be used to = learn the locations of these configuration metadata documents if that = makes sense in the application context.  The editors took WebFinger = out of the OAuth Discovery document since it isn=E2=80=99t always = applicable.

 

            =             &= nbsp;           &n= bsp;           &nb= sp;         Cheers,

            =             &= nbsp;           &n= bsp;           &nb= sp;         -- Mike

 

From:<= /b> John = Bradley [mailto:ve7jtb@ve7jtb.com] =
Sent: Thursday, February 18, 2016 7:41 AM
To: Phil = Hunt <phil.hunt@oracle.com>
C= c: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: 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=E2=80=99t have a = specific protocol identifier then it would use the default. =  

 

I don=E2=80=99t know if you can get = around having some sort of app/protocol identifier configured in the = app.

 

John = B.

 

 

 

 

 

 

On Feb 18, 2016, at 9:49 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

 

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 of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D.

 

Then there is confusion about what = host the discovery is done on.

 

For example, hypothetically do I = do:

 

GET = /.well-known/crm

<= div>

 

But what about the CRM=E2=80=99s = configuration information. Is this stomping on = it?

 

Or, what If we put the oauth = configuration at the host for the crm = service:

GET = /.well-known/openid-configuration

 

I think the point is that there is = a relationship between a protected resource and its designated OAuth = service. 

 

The client needs to = discover:

* Where is its designated resource service and what = security does it use

* If it is OAuth, where is the = intended OAuth configuration for that resource service = instance?

 

<= div>

Phil

 

@independentid

phil.hunt@oracle.com<= /span>

 

 

 

 

On Feb 18, 2016, at 7:19 AM, John = Bradley <ve7jtb@ve7jtb.com> = wrote:

 

Can you clarify what you mean by = =E2=80=9Cresource service x=E2=80=9D?

 

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 SCIM if it exists it is protocol or deployment = specific.

 

The notion that you would send the = URI you are planning on requesting to a Webfinger server to find the = OAuth server, is probably going to have privacy = issues.

 

I suspect that you need to hand = back a error from the resource to say where the AS is, or have a = .well-known for the RS.

 

RS discovery probably wants to be = separate from AS discovery.  (Yes I do think we need something, =  UMA rpt or something like it might be a way to = go)

 

John = B.

 

On Feb 18, 2016, at 9:06 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

 

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 ever written that uses OAuth. Are we expecting 100s of = thousands of these to each register?

 

To me, this specification is a fine = specification for OIDC and it should be published there because the = specification defines how to discovery OAuth and OpenID = information.

 

Likewise you suggest it is ok for = SCIM to do the same. 

 

How do we expect normal = applications to set up and do = discovery?

 

It seems to me that an = =E2=80=9COAUTH=E2=80=9D discovery spec should have a parameter to ask, I = want to discover OAuth configuration for resource service = X.

 

That still allows me to have a = separate discovery service that says, tell me about resource service X = itself.

 

BTW. I think we are FAR from Last = Call on this topic.

 

<= div>

Phil

 

@independentid

phil.hunt@oracle.com<= /span>

 

 

 

 

On Feb 18, 2016, at 6:55 AM, John = Bradley <ve7jtb@ve7jtb.com> = wrote:

 

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 it is better for SCIM to = register one well known than to have to register 20 claims with scim = prefixes or something silly like = that.

 

Name-spacing the claims by allowing = them to be in different well known files is not = unreasonable.

 

Remember some of these protocols = may be hosted on SaaS so there is no guarantee that all protocols will = have the same OAuth Config.

 

Nothing stops a protocol from doing = what it likes with webfinger if it wants to use that for = discovery.

 

In principal I like the idea of = having another protocol as an = example.

 

My only concern is that I = haven=E2=80=99t seen any discussion of your SCIM discovery document in = the SCIM WG.  

I personally think sorting out = discovery for SCIM is a good idea,  but OAUTh is but one of several = authentication methods for SCIM, and there are probably other non OAuth = things that want to be described.

 

I would feel better about using it = as an example if it were adopted by the WG and some general interest = shown.

 

I encourage you to do that so we = can use it as a example.

 

John = B.

 

On Feb 18, 2016, at 8:35 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

 

I still find the following text = objectionable and = confusing=E2=80=A6

   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-configuration" and publish the metadata =
document at
   the =
path formed by concatenating =
"/.well-known/openid-configuration"
   to = the authorization server's issuer identifier.  As described = in
   Section 5, despite the identifier
   =
"/.well-known/openid-configuration", appearing to be =
OpenID-specific,
   its =
usage in this specification is actually referring to a =
general
   OAuth =
2.0 feature that is not specific to OpenID =
Connect.

 

Further, as a default = =E2=80=9Copenid-configuration=E2=80=9D as the default further gives = people the impression that a plain OAuth server *is* an authentication = server and that the normal access token received is evidence of a = successful authentication.

 

It would be better to point out = that application may include oauth discovery in their discovery URI and = that OAuth is an example of this. It might be good to include two = examples.  E.g. OIDC and SCIM (as another referenceable = example).

 

 GET =
/.well-known/openid-configuration

and

 GET =
/.well-known/scim

Retrieve the OAuth configuration = for the application openid and scim = respectively.

 

The use = of:

 GET =
/.well-known/oauth2/

Should be the default used when = there is no known application based well-known application based URI = discovery.

 

Of course, the concern I raised = earlier is that this approach of application specific URIs ends up = requiring every application to make an IANA registration if they = don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (or = =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors = expect?

 

It seemed better to me to use the = webfinger syntax to allow the client to say =E2=80=9CI want the = designated OAuth configuration for the resource service X=E2=80=9D would = be a better design that avoids extensive IANA = registration.

 

<= div>

Phil

 

@independentid

phil.hunt@oracle.com<= /span>

 

 

 

 

On Feb 17, 2016, at 11:48 PM, Mike = Jones <Michael.Jones@microsoft.com> wrote:

 

 =

An = HTML-formatted version is also available at:

 =

  &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       -- Mike & Nat & = John

 =

P.S.  = This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.

____________= ___________________________________
OAuth mailing = list
OAuth@ietf.org
<= span lang=3DEN-US>https://www.ietf.org/mailman/listinfo/oauth

 

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/oauth

 

<= /div>

 

 

<= /div>

 

<= /div>

 

------=_NextPart_000_023F_01D16B20.8DDE80F0--