Subject: [OAUTH-WG] Initial OAuth working group Discovery specification

From: Mike Jones <[email-masked]>
Date: Tue, 9 Feb 2016 14:09:06 +0000

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:

*       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00

An HTML-formatted version is also available at:

*       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html

                                                          -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1534 and as @selfissued<https://twitter.com/selfissued>.

---

From: Justin Richer <[email-masked]>
Date: Tue, 9 Feb 2016 12:19:40 -0500

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” to "/.well-known/oauth-authorization-server” or something else not openid-related.

 — Justin

> On Feb 9, 2016, at 9:09 AM, Mike Jones <[email-masked]> wrote:
> 
> ·       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 <http://tools.ietf.org/html/draft-ietf-oauth-discovery-00>
>  
> ·       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html <http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html>
>  
>                                                           -- Mike
>  
> P.S.  This notice was also posted at http://self-issued.info/?p=1534 <http://self-issued.info/?p=1534> and as @selfissued <https://twitter.com/selfissued>.
>  
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Tue, 9 Feb 2016 19:03:51 -0300

If we keep webfinger I don’t think that having a generic OAuth rel makes sense.   It should be up to each API/Protocol to define it’s 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 <[email-masked]> wrote:
> 
>> On Feb 9, 2016, at 9:09 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Justin Richer <[email-masked]>
Date: Tue, 9 Feb 2016 17:18:57 -0500

Webfinger without a rel= doesn’t make much sense for us to define, does it? What output value is the client going to look for in the response, then? I’m with John that we should let applications define their own rel= values and therefore leave webfinger out entirely.

I don’t buy the historical compatibility argument here, and keep in mind I’m an implementer who will need to support both endpoints if we do split it. I already have a server that supports both /.well-known/openid-configuration and /.well-known/uma-configuration so I’m not at all worried about the perceived overhead. If a protocol like OIDC wants to replicate the information in the OAuth discovery document, that’s fine. If it wants to instead reference the OAuth discovery document for the OAuth values, that’s also fine. But that’s a decision up to the application protocol that’s using OAuth.

It’s much cleaner to define something new and keep it structurally compatible (or at least not incompatible) with the OIDC version.

 — Justin

> On Feb 9, 2016, at 5:03 PM, John Bradley <[email-masked]> wrote:
> 
>> On Feb 9, 2016, at 2:19 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 9 Feb 2016 14:39:45 -0800

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=oauth&query=rs:scim&acnt:[email-masked]

Note i probably have the compound query syntax wrong. 

Phil

> On Feb 9, 2016, at 14:03, John Bradley <[email-masked]> wrote:
> 
>>> ·       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
>>>  
>>> ·       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html
>>>  
>>>                                                           -- Mike
>>>  
>>> P.S.  This notice was also posted at http://self-issued.info/?p=1534 and as @selfissued.
>>>

---

From: John Bradley <[email-masked]>
Date: Tue, 9 Feb 2016 19:52:52 -0300

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’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) <[email-masked]> wrote:
> 
> Get ./well-known/webfinger?rel=oauth&query=rs:scim&acnt:[email-masked] <http://example.com/>
> 
> On Feb 9, 2016, at 14:03, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 9 Feb 2016 15:03:23 -0800

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 <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Tue, 9 Feb 2016 20:16:20 -0300

Please don’t 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) <[email-masked]> wrote:
> 
> On Feb 9, 2016, at 14:52, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 9 Feb 2016 15:24:01 -0800

Huh?

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

Further, having rel=oauth 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.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Feb 9, 2016, at 3:16 PM, John Bradley <[email-masked]> wrote:
> 
>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Tue, 9 Feb 2016 20:49:39 -0300

Have a look at
https://tools.ietf.org/html/rfc7033 <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’t 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 <[email-masked]> wrote:
> 
> Huh?
> 
>> On Feb 9, 2016, at 3:16 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 9 Feb 2016 16:20:17 -0800

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)…the proper query that returns information for both SCIM and OAuth endpoints would be:

GET /.well-known/webfinger?resource=https://scim.example.com&rel=oauth

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

     {
       "subject" : “http://scim.example.com",
      
       "links" :
       [
         {
           "rel" : “oauth",
           "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. “acct” is just one scheme. Others can be defined. For example, “rs:” 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=rs:scim&rel=oauth

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

     {
       "subject" : “rs:scim",
      
       "links" :
       [
         {
           "rel" : “oauth",
           "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

> On Feb 9, 2016, at 3:49 PM, John Bradley <[email-masked]> wrote:
> 
> Have a look at
>> On Feb 9, 2016, at 8:24 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Huh?
>>

---

From: John Bradley <[email-masked]>
Date: Tue, 9 Feb 2016 21:34:02 -0300

OK I was talking about discovering user services via webfinger, (The way connect uses it and most other things) and you are talking about using it to discover things about a server.

Your first example had [email-masked] as the account you were querying, and that seemed like a user discovery to me.

If you are looking up the OAuth config for a server why would you not just go strait to the .wellknown 

By the way in your example you would need to run a webfinger server on scim.example.com to be able to answer the query. 

looking for .wellknown on examle.com seems more direct.

You seem to be looking more for where is the service for the domain rather than the user.

John B.

> On Feb 9, 2016, at 9:20 PM, Phil Hunt <[email-masked]> wrote:
> 
> John,
> 
> GET /.well-known/webfinger?resource=https://scim.example.com&rel=oauth <https://scim.example.com&rel=oauth>
> 
>        "subject" : “http://scim.example.com <http://scim.example.com/>",
>       
>        "links" :
>        [
>          {
>            "rel" : “oauth",
>            "href" : "https://oauth.example.com/ <https://oauth.example.com/>"
>          }
>        ]
>      }
> 
> This tells me that the OAuth server used for SCIM at scim.example.com <http://scim.example.com/> is at oauth.example.com <http://oauth.example.com/>
> 
>            "href" : "https://oauth.example.com/ <https://oauth.example.com/>"
>          }
>        ]
>      }
> 
> This says something different.  This says that for scim services the oauth service is oauth.example.com <http://oauth.example.com/>.
> 
>> On Feb 9, 2016, at 3:49 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Have a look at

---

From: Justin Richer <[email-masked]>
Date: Tue, 9 Feb 2016 21:00:53 -0500

+1 to John’s point. Webfinger is, as designed, about doing per-user service discovery. Let’s keep the OAuth service discovery away from that. What does it mean to find the OAuth server for a user, anyway? Without the context of a resource protocol, I don’t think it does. If you already have the domain and you don’t need to do a transform from a user-identifier, just go straight to .well-known and have an OAuth service discovery document.

I think the current discovery draft has tried much too hard to copy what’s in OIDC, where it does make sense to use webfinger and per-user discovery systems in the context of a specific identity protocol. It’s a great starting place, but I think we decidedly need to get away from it now.

 — Justin

> On Feb 9, 2016, at 7:34 PM, John Bradley <[email-masked]> wrote:
> 
> Your first example had [email-masked] <mailto:[email-masked]> as the account you were querying, and that seemed like a user discovery to me.
> 
> By the way in your example you would need to run a webfinger server on scim.example.com <http://scim.example.com/> to be able to answer the query.
> 
> looking for .wellknown on examle.com <http://examle.com/> seems more direct.
> 
>> On Feb 9, 2016, at 9:20 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> John,
>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 10 Feb 2016 00:10:08 -0800

Justin,

The abstract to 7033 says.

   This specification defines the WebFinger protocol, which can be used
   to discover information about people or other entities on the
   Internet using standard HTTP methods.  WebFinger discovers
   information for a URI that might not be usable as a locator
   otherwise, such as account or email URIs.

I am pushing on this because I think we really need to bind the resource service into discovery somehow. The RS is just as important as the other oauth endpoints.

If a client can be convinced or configured to use a fake resource server (that proxies the real one), then we have the same problem as a client being convinced to use a fake token endpoint — only much worse.

I don’t get the big taboo against webfinger here. We don’t have to use webfinger - but are you arguing for something completely different? A new protocol? Since OIDC already started the ball rolling with webfinger, it seems worth while trying to use it.

What am I missing here?

Phil

@independentid

> On Feb 9, 2016, at 6:00 PM, Justin Richer <[email-masked]> wrote:
> 
>> On Feb 9, 2016, at 7:34 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 10 Feb 2016 08:40:26 -0500

Yes, it says that because we can't ever talk about people as being the 
only things in the world. The purpose of webfinger is to take something 
that's easily human-memorizable, like an email-formatted identifier, and 
transform it into an HTTPS URL that can be fetched with GET. It's true 
that you could have an organization or bot or other entity that you want 
to refer to with a [email-masked] type of format, sure. But I argue 
that if you're talking about a resource server, you're likely to already 
have a URL that you can put in to the .well-known discovery step. You 
don't need the human-readable transform to do what you're talking about 
below in any of the use cases, you just need the service discovery 
document part.

Additionally, we all three actually agree about the importance of 
discovery from a resource server, except that John and I couched that in 
"knowing the specific API" and having that API define its first-stage 
discovery process. OIDC used webfinger because it makes sense to have a 
human-readable identifier for an identity protocol. It probably makes 
sense to have SCIM define its own webfinger REL as well since you've got 
entity identifiers all over the place. But it doesn't really make sense 
for OAuth, and especially not the multi-part resource you're talking 
about below.

And to add just a bit from personal experience, we actually just relaxed 
and simplified our webfinger implementation so that it returns the same 
document regardless of what REL you asked for anyway, which is pretty 
common with the handful of webfinger servers that I've seen in the wild.

  -- Justin

On 2/10/2016 3:10 AM, Phil Hunt wrote:
>     to discover information about people_or other entities on the Internet_  using standard HTTP methods.  WebFinger discovers
> I am pushing on this because I think we really need to bind the 
> resource service into discovery somehow. The RS is just as important 
> as the other oauth endpoints.
>
> If a client can be convinced or configured to use a fake resource 
> server (that proxies the real one), then we have the same problem as a 
> client being convinced to use a fake token endpoint — only much worse.
>
> I don’t get the big taboo against webfinger here. We don’t have to use 
> webfinger - but are you arguing for something completely different? A 
> new protocol? Since OIDC already started the ball rolling with 
> webfinger, it seems worth while trying to use it.
>
> What am I missing here?
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>> On Feb 9, 2016, at 6:00 PM, Justin Richer <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> +1 to John’s point. Webfinger is, as designed, about doing per-user 
>> service discovery. Let’s keep the OAuth service discovery away from 
>> that. What does it mean to find the OAuth server for a user, anyway? 
>> Without the context of a resource protocol, I don’t think it does. If 
>> you already have the domain and you don’t need to do a transform from 
>> a user-identifier, just go straight to .well-known and have an OAuth 
>> service discovery document.
>>
>> I think the current discovery draft has tried much too hard to copy 
>> what’s in OIDC, where it does make sense to use webfinger and 
>> per-user discovery systems in the context of a specific identity 
>> protocol. It’s a great starting place, but I think we decidedly need 
>> to get away from it now.
>>
>>  — Justin
>>
>>> OK I was talking about discovering user services via webfinger, (The 
>>> way connect uses it and most other things) and you are talking about 
>>> using it to discover things about a server.
>>>
>>> Your first example had [email-masked] <mailto:[email-masked]> 
>>> as the account you were querying, and that seemed like a user 
>>> discovery to me.
>>>
>>> By the way in your example you would need to run a webfinger server 
>>> on scim.example.com <http://scim.example.com/> to be able to answer 
>>> the query.
>>>
>>>> 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)…the proper query that returns information for both SCIM and 
>>>> OAuth endpoints would be:
>>>>
>>>> This tells me that the OAuth server used for SCIM at 
>>>> scim.example.com <http://scim.example.com/> is at oauth.example.com 
>>>> <http://oauth.example.com/>
>>>>
>>>> Note that 7033 has an extension mechanism to define other schemes. 
>>>> E.g. “acct” is just one scheme. Others can be defined. For example, 
>>>> “rs:” could be registered allowing URIs to be used for the resource 
>>>> instead of an actual https endpoint (which is also allowed).
>>>>
>>>> This says something different.  This says that for scim services 
>>>> the oauth service is oauth.example.com <http://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 <http://www.independentid.com/>
>>>> [email-masked] <mailto:[email-masked]>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 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 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.
>>>>>
>>>>> I don’t 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.
>>>>>
>>>>>> Our proposals are the opposite of one-another.  In your proposal 
>>>>>> you have people querying scim to get oauth.  I’m saying you query 
>>>>>> rel=scim to get information about SCIM.  Querying rel=SCIM and 
>>>>>> receiving OAuth seems bass- ackwards does it not?
>>>>>>
>>>>>> Further, having rel=oauth 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.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> @independentid
>>>>>> www.independentid.com <http://www.independentid.com/>
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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.
>>>>>>>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) 
>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> I don’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) 
>>>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>>
>>>>>>>>>> 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=oauth&query=rs:scim&acnt:[email-masked] 
>>>>>>>>>> <http://example.com/>
>>>>>>>>>>
>>>>>>>>>>> If we keep webfinger I don’t think that having a generic 
>>>>>>>>>>> OAuth rel makes sense.   It should be up to each 
>>>>>>>>>>> API/Protocol to define it’s 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 2) The changing of "/.well-known/openid-configuration” to 
>>>>>>>>>>>> "/.well-known/oauth-authorization-server” or something else 
>>>>>>>>>>>> not openid-related.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  — Justin
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones 
>>>>>>>>>>>>> <[email-masked] 
>>>>>>>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> We have created the initial working group version of OAuth 
>>>>>>>>>>>>> Discovery based on draft-jones-oauth-discovery-01, with no 
>>>>>>>>>>>>> normative changes.
>>>>>>>>>>>>> ·http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
>>>>>>>>>>>>> ·http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html
>>>>>>>>>>>>> -- Mike
>>>>>>>>>>>>> P.S. This notice was also posted 
>>>>>>>>>>>>> athttp://self-issued.info/?p=1534and as@selfissued 
>>>>>>>>>>>>> <https://twitter.com/selfissued>.

---

From: George Fletcher <[email-masked]>
Date: Wed, 10 Feb 2016 13:10:07 -0500

I have to disagree that Webfinger is just about *per-user* service 
discovery. It can definitely be used that way, but even in the spec 
there is the example of finding the meta data about a resource which 
includes in the JSON response a "rel":"author". Which means webfinger is 
designed for queries such as "who is the author of this webpage".

GET 
/.well-known/webfinger?resource=http%3A%2F%2Fblog.example.com%2Farticle%2Fid%2F314&rel=author

I do agree that OAuth should focus on the details of the discovery 
document and possibly its location within .well-known.

Thanks,
George

On 2/9/16 9:00 PM, Justin Richer wrote:
> what’s in OIDC, where it does make sense to use webfinger and per-user 
> discovery systems in the context of a specific identity protocol. It’s 
> a great starting place, but I think we decidedly need to get away from 
> it now.
>
>  — Justin
>
>>> This says something different.  This says that for scim services the 
>>> oauth service is oauth.example.com <http://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
>>>> 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.
>>>>
>>>>> 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.
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>>> Webfinger is designed to be very simple to implement.  In general 
>>>>>> you just get back the whole document with all the rel.
>>>>>>>> sub properties if it supported more than one auth type,  or you 
>>>>>>>> could have a SCIM discovery document that the URI points to.
>>>>>>>>
>>>>>>>> the account identity may mean different things depending on the 
>>>>>>>> protocol, and not every protocol needs per user discovery.
>>>>>>>>
>>>>>>>> John B
>>>>>>>>> relation.  So may be we need a scheme for oauth where query is 
>>>>>>>>> rs:someval and optionally an acnt value to.
>>>>>>>>>
>>>>>>>>> For example
>>>>>>>>> Get 
>>>>>>>>>> OAuth rel makes sense.   It should be up to each API/Protocol 
>>>>>>>>>> to define it’s own rel value like Connect has done.
>>>>>>>>>>
>>>>>>>>>> going to be the same as the one for calendaring or photo sharing.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>

---

From: "Nat Sakimura" <[email-masked]>
Date: Fri, 12 Feb 2016 18:00:15 +0900

Sorry to chime in a bit late, but IMHO, the discovery document discovery etc. starting from the protected resource should happen via RFC5988. 

That is, when the client asks for the access, it gets an error like: 

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Bearer realm="example"

Link: <https://example.com/.well-known/openid-configuration>; rel="duri",

  <https://example.net/.well-known/openid-configuration>; rel="duri",

   <https://example.com/payment-upon-trial-expiry>; rel="payments"

I used .well-known/openid-configuration in the example, but it does not have to be. It can be anything. It does not pollute the server uri space this way and can support multiple authorization servers. 

See:  <http://www.sakimura.org/uploads/draft-sakimura-oauth-meta.html#rfc.section.2> http://www.sakimura.org/uploads/draft-sakimura-oauth-meta.html#rfc.section.2

Best, 

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.

From: OAuth [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, February 10, 2016 10:40 PM
To: Phil Hunt
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification

Yes, it says that because we can't ever talk about people as being the only things in the world. The purpose of webfinger is to take something that's easily human-memorizable, like an email-formatted identifier, and transform it into an HTTPS URL that can be fetched with GET. It's true that you could have an organization or bot or other entity that you want to refer to with a [email-masked] <mailto:[email-masked]>  type of format, sure. But I argue that if you're talking about a resource server, you're likely to already have a URL that you can put in to the .well-known discovery step. You don't need the human-readable transform to do what you're talking about below in any of the use cases, you just need the service discovery document part. 

Additionally, we all three actually agree about the importance of discovery from a resource server, except that John and I couched that in "knowing the specific API" and having that API define its first-stage discovery process. OIDC used webfinger because it makes sense to have a human-readable identifier for an identity protocol. It probably makes sense to have SCIM define its own webfinger REL as well since you've got entity identifiers all over the place. But it doesn't really make sense for OAuth, and especially not the multi-part resource you're talking about below. 

And to add just a bit from personal experience, we actually just relaxed and simplified our webfinger implementation so that it returns the same document regardless of what REL you asked for anyway, which is pretty common with the handful of webfinger servers that I've seen in the wild.

 -- Justin

Justin, 

What am I missing here?

Phil

@independentid

 

On Feb 9, 2016, at 6:00 PM, Justin Richer <[email-masked] <mailto:[email-masked]> > wrote:

 — Justin

On Feb 9, 2016, at 7:34 PM, John Bradley <[email-masked] <mailto:[email-masked]> > wrote:

 

John B.

On Feb 9, 2016, at 9:20 PM, Phil Hunt <[email-masked] <mailto:[email-masked]> > wrote:

John, 

GET /.well-known/webfinger?resource=https://scim.example.com <https://scim.example.com&rel=oauth> &rel=oauth

     HTTP/1.1 200 OK
 
     {
       "subject" : “http://scim.example.com <http://scim.example.com/> ",
      
       "links" :
       [
         {
           "rel" : “oauth",

     HTTP/1.1 200 OK
 
     {
       "subject" : “rs:scim",
      
       "links" :
       [
         {
           "rel" : “oauth",

This says something different.  This says that for scim services the oauth service is oauth.example.com <http://oauth.example.com/> .

 

Phil

@independentid

 

On Feb 9, 2016, at 3:49 PM, John Bradley <[email-masked] <mailto:[email-masked]> > wrote:

Have a look at

John B.

On Feb 9, 2016, at 8:24 PM, Phil Hunt <[email-masked] <mailto:[email-masked]> > wrote:

Huh? 

Phil

@independentid

 

On Feb 9, 2016, at 3:16 PM, John Bradley <[email-masked] <mailto:[email-masked]> > wrote:

On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]> > wrote:

Phil

On Feb 9, 2016, at 14:52, John Bradley <[email-masked] <mailto:[email-masked]> > wrote:

John B

On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]> > wrote:

For example

Phil

On Feb 9, 2016, at 14:03, John Bradley <[email-masked] <mailto:[email-masked]> > wrote:

John B.

On Feb 9, 2016, at 2:19 PM, Justin Richer <[email-masked] <mailto:[email-masked]> > wrote:

 

 

 — Justin

On Feb 9, 2016, at 9:09 AM, Mike Jones <[email-masked] <mailto:[email-masked]> > wrote:

                                                          -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1534 and as @selfissued <https://twitter.com/selfissued> .