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 C118B1B2A6C for ; Tue, 9 Feb 2016 16:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 iWvF_R5Cqfcu for ; Tue, 9 Feb 2016 16:20:24 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFC31B2A68 for ; Tue, 9 Feb 2016 16:20:24 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1A0KN9W019398 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Feb 2016 00:20:23 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u1A0KMic008061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Feb 2016 00:20:22 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1A0KMlw003727; Wed, 10 Feb 2016 00:20:22 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Feb 2016 16:20:21 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_B02B826D-FADC-4A76-B857-E5BB379A8002" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: Date: Tue, 9 Feb 2016 16:20:17 -0800 Message-Id: <6580B8BC-49CD-4DF3-8056-ABD7F785E613@oracle.com> References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> To: John Bradley X-Mailer: Apple Mail (2.3112) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification 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: Wed, 10 Feb 2016 00:20:29 -0000 --Apple-Mail=_B02B826D-FADC-4A76-B857-E5BB379A8002 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 John, I am following 7033. The rel parameter is not the query it is the sub = set of the resource you want information about. There is nothing complex here. In most cases this would be responded to = by a simple transformation pattern. Correcting my previous example (but showing it in easy to read = form)=E2=80=A6the proper query that returns information for both SCIM = and OAuth endpoints would be: GET /.well-known/webfinger?resource=3Dhttps://scim.example.com&rel=3Doauth= This would return something like: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Content-Type: application/jrd+json { "subject" : =E2=80=9Chttp://scim.example.com", =20 "links" : [ { "rel" : =E2=80=9Coauth", "href" : "https://oauth.example.com/" } ] } This tells me that the OAuth server used for SCIM at scim.example.com is = at oauth.example.com Note that 7033 has an extension mechanism to define other schemes. E.g. = =E2=80=9Cacct=E2=80=9D is just one scheme. Others can be defined. For = example, =E2=80=9Crs:=E2=80=9D could be registered allowing URIs to be = used for the resource instead of an actual https endpoint (which is also = allowed). GET /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth This would return something like: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Content-Type: application/jrd+json { "subject" : =E2=80=9Crs:scim", =20 "links" : [ { "rel" : =E2=80=9Coauth", "href" : "https://oauth.example.com/" } ] } This says something different. This says that for scim services the = oauth service is oauth.example.com. The first example actually has more granularity. The second example = does not require the client to know the scim endpoint in advance. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 9, 2016, at 3:49 PM, John Bradley wrote: >=20 > Have a look at > https://tools.ietf.org/html/rfc7033 = >=20 > The way to do what you want would mean having multiple array objects = with the same rel and somehow differentiating them via properties. >=20 > I think that is going to be more complicated for clients to parse. >=20 > I think that the difference is how you look at the actors involved. I = think clients look for a service and then go from there, you are = advocating that they would look for a authorization method and then find = services that support that method. =20 >=20 > So yes we are looking at it from different ends. >=20 > I don=E2=80=99t know that defining OAuth genericly at the webfinger = level of user discovery makes sense. Perhaps for a enterprise custom = API environment it might. >=20 > John B. >=20 >> On Feb 9, 2016, at 8:24 PM, Phil Hunt > wrote: >>=20 >> Huh? >>=20 >> Our proposals are the opposite of one-another. In your proposal you = have people querying scim to get oauth. I=E2=80=99m saying you query = rel=3Dscim to get information about SCIM. Querying rel=3DSCIM and = receiving OAuth seems bass- ackwards does it not? >>=20 >> Further, having rel=3Doauth lets us define one RFC for all that = covers all the security concerns for oauth discovery. If we do it your = way then every resource that registers its own discovery also has to = have an oauth section that copies the oauth discovery stuff because = there is no longer an oauth discovery relationship. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Feb 9, 2016, at 3:16 PM, John Bradley > wrote: >>>=20 >>> Please don=E2=80=99t break the webfinger RFC. >>>=20 >>> If you search for SCIM you can have additional properties returned = as part of the entry, but you only search for one thing. >>> =20 >>> Webfinger is designed to be very simple to implement. In general = you just get back the whole document with all the rel.=20 >>> The query filter is a optional optimization.=20 >>>=20 >>> The JSON in the doc is by rel. >>>=20 >>>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) > wrote: >>>>=20 >>>> The rel for scim returns the endpoint for scim.=20 >>>>=20 >>>> The rel for oauth returns endpoints for oauth.=20 >>>>=20 >>>> The query lets the client say i want the endpoint for oauth used = for scim.=20 >>>>=20 >>>> I suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-) >>>>=20 >>>> Phil >>>>=20 >>>> On Feb 9, 2016, at 14:52, John Bradley > wrote: >>>>=20 >>>>> You would define a rel uri for SCIM. The SCIM entry can have sub = properties if it supported more than one auth type, or you could have a = SCIM discovery document that the URI points to. >>>>>=20 >>>>> There are probably multiple ways to do it. >>>>>=20 >>>>> I don=E2=80=99t think trying to have a oauth rel and then sub = types is going to make sense to developers. It is also not a good fit = for Webfinger. >>>>>=20 >>>>> I also suspect that SCIM is more naturally part of a = authentication service It may be that the authentication service points = at the SCIM service. >>>>>=20 >>>>> Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as. >>>>>=20 >>>>> Each service will need to be thought through for webfinger as the = account identity may mean different things depending on the protocol, = and not every protocol needs per user discovery. >>>>>=20 >>>>> John B >>>>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) > wrote: >>>>>>=20 >>>>>> Another example is to look at scim discovery(in contrast with = connect). >>>>>>=20 >>>>>> When asked separately the answers may be different.=20 >>>>>>=20 >>>>>> Asking what is the oauth server for scim is yet another relation. = So may be we need a scheme for oauth where query is rs:someval and = optionally an acnt value to.=20 >>>>>>=20 >>>>>> For example >>>>>> Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com = >>>>>>=20 >>>>>> Note i probably have the compound query syntax wrong.=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On Feb 9, 2016, at 14:03, John Bradley > wrote: >>>>>>=20 >>>>>>> If we keep webfinger I don=E2=80=99t think that having a generic = OAuth rel makes sense. It should be up to each API/Protocol to define = it=E2=80=99s own rel value like Connect has done. >>>>>>>=20 >>>>>>> It is not reasonable to think that a persons ID provider is = going to be the same as the one for calendaring or photo sharing. >>>>>>>=20 >>>>>>> So I could go two ways with webfinger, leave it out completely, = or leave it in but make it up to the application to define a rel value. >>>>>>> I expect that some things using UMA in web-finger would point = directly to the resource and the resource would point the client at the = correct UMA server. >>>>>>>=20 >>>>>>> The config file name in .well-known could stay as = openid-configuration for historical reasons or we could change it. >>>>>>>=20 >>>>>>> I think we first need to decide if every protocol/API is going = to have its own config file, we are going to get apps to retrieve = multiple files, or everything is going to go into one config-file and = applicatins just add to that? >>>>>>>=20 >>>>>>> I prefer not to change the file name if we are going for one = config file, but if we do one alias/link is probably not the end of the = world, as I doubt people will ever remove openid-configuration one if = they have it now. >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>> =20 >>>>>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: >>>>>>>>=20 >>>>>>>> Mike, thanks for putting this up. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I would like to propose for two changes that have been brought = up before: >>>>>>>>=20 >>>>>>>> 1) The wholesale removal of section 2, Webfinger lookup.=20 >>>>>>>>=20 >>>>>>>> 2) The changing of "/.well-known/openid-configuration=E2=80=9D = to "/.well-known/oauth-authorization-server=E2=80=9D or something else = not openid-related. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones = > = wrote: >>>>>>>>>=20 >>>>>>>>> We have created the initial working group version of OAuth = Discovery based on draft-jones-oauth-discovery-01, with no normative = changes. >>>>>>>>> =20 >>>>>>>>> The specification is available at: >>>>>>>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >>>>>>>>> =20 >>>>>>>>> An HTML-formatted version is also available at: >>>>>>>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >>>>>>>>> =20 >>>>>>>>> -- = Mike >>>>>>>>> =20 >>>>>>>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1534 = and as @selfissued . >>>>>>>>> =20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> 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 = >>>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_B02B826D-FADC-4A76-B857-E5BB379A8002 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 John,

I = am following 7033.  The rel parameter is not the query it is the = sub set of the resource you want information about.

There is nothing complex = here. In most cases this would be responded to by a simple = transformation pattern.

Correcting my previous example (but showing it in easy to = read form)=E2=80=A6the proper query that returns information for both = SCIM and OAuth endpoints would be:

GET = /.well-known/webfinger?resource=3Dhttps://scim.example.com&rel=3Doauth

This = would return something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : =E2=80=9Chttp://scim.example.com",
     =20
       "links" :
       [
         {
           "rel" : =
=E2=80=9Coauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This tells me that the OAuth server used for = SCIM at scim.example.com is at oauth.example.com

Note that 7033 has an extension = mechanism to define other schemes. E.g. =E2=80=9Cacct=E2=80=9D is just = one scheme. Others can be defined. For example, =E2=80=9Crs:=E2=80=9D = could be registered allowing URIs to be used for the resource instead of = an actual https endpoint (which is also allowed).

GET = /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth

This would return = something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : =E2=80=9Crs:scim",
     =20
       "links" :
       [
         {
           "rel" : =E2=80=9Coauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This = says something different.  This says that for scim services the = oauth service is oauth.example.com.

The first example actually has more = granularity.  The second example does not require the client to = know the scim endpoint in advance.





On Feb 9, 2016, at 3:49 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Have a look at
https://tools.ietf.org/html/rfc7033

The way to do what you want would mean = having multiple array objects with the same rel and somehow = differentiating them via properties.

I think that is going to be more = complicated for clients to parse.

I think that the difference is how you = look at the actors involved.  I think clients look for a service = and then go from there,  you are advocating that they would look = for a authorization method and then find services that support that = method.   

So yes we are looking at it from different ends.

I don=E2=80=99t know = that defining OAuth genericly at the webfinger level of user discovery = makes sense.   Perhaps for a enterprise custom API environment it = might.

John = B.

On Feb 9, 2016, at 8:24 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Huh?

Our proposals are the = opposite of one-another.  In your proposal you have people querying = scim to get oauth.  I=E2=80=99m saying you query rel=3Dscim to get = information about SCIM.  Querying rel=3DSCIM and receiving OAuth = seems bass- ackwards does it not?

Further, having rel=3Doauth lets us = define one RFC for all that covers all the security concerns for oauth = discovery.  If we do it your way then every resource that registers = its own discovery also has to have an oauth section that copies the = oauth discovery stuff because there is no longer an oauth discovery = relationship.





On Feb 9, 2016, at 3:16 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Please don=E2=80= =99t break the webfinger RFC.

If you search for SCIM you can have additional properties = returned as part of the entry, but you only search for one = thing.
 
Webfinger is = designed to be very simple to implement.  In general you just get = back the whole document with all the rel. 
The = query filter is a optional optimization. 

The JSON in the doc is by = rel.

On Feb 9, 2016, at 8:03 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

The rel for scim = returns the endpoint for scim. 

The rel for oauth returns endpoints for = oauth. 

The= query lets the client say i want the endpoint for oauth used for = scim. 

I = suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> = wrote:

You would define a rel = uri for SCIM.   The SCIM entry can have sub properties if it = supported more than one auth type,  or you could have a SCIM = discovery document that the URI points to.

There are probably multiple ways to do = it.

I don=E2=80=99= t think trying to have a oauth rel and then sub types is going to make = sense to developers.  It is also not a good fit for = Webfinger.

I = also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service.

Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as.

Each service will need to be thought = through for webfinger as the account identity may mean different things = depending on the protocol, and not every protocol needs per user = discovery.

John = B
On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

Another example = is to look at scim discovery(in contrast with connect).

When asked separately = the answers may be different. 

Asking what is the oauth server for = scim is yet another relation.  So may be we need a scheme for oauth = where query is rs:someval and optionally an acnt value = to. 

For = example
Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com

Note i probably have the = compound query syntax wrong. 

Phil

On Feb 9, 2016, at = 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think = that having a generic OAuth rel makes sense.   It should be up to = each API/Protocol to define it=E2=80=99s own rel value like Connect has = done.

It is not = reasonable to think that a persons ID provider is going to be the same = as the one for calendaring or photo sharing.

So I could go two ways with webfinger, =  leave it out completely, or leave it in but make it up to the = application to define a rel value.
I expect that = some things using UMA in web-finger would point directly to the resource = and the resource would point the client at the correct UMA = server.

The = config file name in .well-known could stay as openid-configuration for historical reasons or we could = change it.

I think we = first need to decide if every protocol/API is going to have its own = config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, = Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


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

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.
 
_________________________________= ______________
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





= --Apple-Mail=_B02B826D-FADC-4A76-B857-E5BB379A8002--