Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery

From: Brian Campbell <[email-masked]>
Date: Tue, 2 Feb 2016 16:02:13 -0700

I agree (kind of anyway) with Torsten. Discovery based on the user id of
the resource owner doesn't necessarily make sense for general OAuth cases.

Also restating what I already posted about the draft: Would it be worth
considering constraining the scope of this document to just the publication
and content of AS metadata? And keep the actual discovery of that metadata,
be it from the RS or the user id or what have you, out of scope or in a
different document(s)? The former is relatively well understood and
provides some value. While the ideas about how the the latter should work
seem to have a pretty broad range.

On Tue, Jan 26, 2016 at 12:35 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> Hi,
>
> I support the adoption of this document as starting point for our work
> towards OAuth discovery.
>
> Restating what I already posted after the last IETF meeting: It seems the
> document assumes the AS can always be discoverd using the user id of the
> resource owner. I think the underlying assumption is resource servers
> accept access token of different (any?) user specific AS (and OP)? From my
> perspective, RSs nowadays typically trust _the_ AS of their security
> domain/ecosystem and all resource owners need to have an user account with
> this particular AS. So I would assume the process to start at the RS. I
> think the spec needs to cover the latter case as well.
>
> kinds regards,
> Torsten.
>
>
> Am 19.01.2016 um 12:48 schrieb Hannes Tschofenig:
>
> Hi all,
>
> this is the call for adoption of OAuth 2.0 Discovery, seehttps://tools.ietf.org/html/draft-jones-oauth-discovery-00
>
> Please let us know by Feb 2nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Note: If you already stated your opinion at the IETF meeting in Yokohama
> then you don't need to re-state your opinion, if you want.
>
> The feedback at the Yokohama IETF meeting was the following: 19 for /
> zero against / 4 persons need more information.
>
> Ciao
> Hannes & Derek
>
>
>
>
> _______________________________________________
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 2 Feb 2016 15:48:56 -0800

I have two separate comments here:

Item 1: Regarding Torsten’s comment

I think there are two scenarios….
A. The client, not knowing who the user is wants to discover the appropriate OAuth endpoint - a generic discovery via ./well-known/oauth

Or wants to discover the OAuth server for a particular web resource.  Maybe a webfinger query that is resource=service:someurl  is more appropriate.

B.  A server wants to discover the OAuth endpoint based on an account identifier for the user. This is appropriate particularly when cloud service providers run multiple oauth tenancies.   (I don’t believe we have this case).

Item 2:  rel value for webfinger
It seems to me while the discovery requirements for plain OAuth and OIDC are the same for today that might not always be true.  What will happen if OIDC wants to add more stuff?  Will plain oAuth sites have to comply?

A client may want to know both the OAuth discovery endpoint information for a resource AND it might want to know the OIDC discovery information.  They endpoints might not always be the same - how do we tell them apart?

I don’t see a big inter-op issue.  Implementation is easy - support for rel=oauth might be as simple as making rel=oauth an alias for rel=http://openid.net/specs/connect/1.0/issuer.  OIDC clients can continue to use rel=http://openid.net/specs/connect/1.0/issuer

Phil

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

> On Feb 2, 2016, at 3:02 PM, Brian Campbell <[email-masked]> wrote:
> 
> I agree (kind of anyway) with Torsten. Discovery based on the user id of the resource owner doesn't necessarily make sense for general OAuth cases. 
> 
> Also restating what I already posted about the draft: Would it be worth considering constraining the scope of this document to just the publication and content of AS metadata? And keep the actual discovery of that metadata, be it from the RS or the user id or what have you, out of scope or in a different document(s)? The former is relatively well understood and provides some value. While the ideas about how the the latter should work seem to have a pretty broad range. 
> 
> On Tue, Jan 26, 2016 at 12:35 PM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> I support the adoption of this document as starting point for our work towards OAuth discovery.
> 
> Restating what I already posted after the last IETF meeting: It seems the document assumes the AS can always be discoverd using the user id of the resource owner. I think the underlying assumption is resource servers accept access token of different (any?) user specific AS (and OP)? From my perspective, RSs nowadays typically trust _the_ AS of their security domain/ecosystem and all resource owners need to have an user account with this particular AS. So I would assume the process to start at the RS. I think the spec needs to cover the latter case as well. 
> 
> kinds regards,
> Torsten.
> 
> 
>> this is the call for adoption of OAuth 2.0 Discovery, see
>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00 <https://tools.ietf.org/html/draft-jones-oauth-discovery-00>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 4 Feb 2016 06:27:04 +0000

I support adoption of this document by the working group.  I'll note that elements of this specification are already in production use by multiple parties.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, January 19, 2016 3:49 AM
To: [email-masked]
Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery

Hi all,

this is the call for adoption of OAuth 2.0 Discovery, see
https://tools.ietf.org/html/draft-jones-oauth-discovery-00

Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group.

Note: If you already stated your opinion at the IETF meeting in Yokohama then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 19 for / zero against / 4 persons need more information.

Ciao
Hannes & Derek

---

From: William Denniss <[email-masked]>
Date: Wed, 3 Feb 2016 22:44:15 -0800

+1 for adoption of this document by the working group

On Wed, Feb 3, 2016 at 10:27 PM, Mike Jones <[email-masked]>
wrote:

> I support adoption of this document by the working group.  I'll note that
> elements of this specification are already in production use by multiple
> parties.
>
>                                 -- Mike
>
> Please let us know by Feb 2nd whether you accept / object to the adoption
> of this document as a starting point for work in the OAuth working group.
>
> The feedback at the Yokohama IETF meeting was the following: 19 for / zero
> against / 4 persons need more information.
>
> Ciao
> Hannes & Derek
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 3 Feb 2016 23:10:40 -0800

+1 for adoption.  

However I would like a rel value distinct from OpenID (see separate email). While the mechanics of discovery is the same, I believe some clients will want to distinguish between OAuth AS’s and OIDC OPs.  Further, I would expect over time that different discovery features may be required. Locking them together seems like a pre-mature or rush choice.

Phil

@independentid

> On Feb 3, 2016, at 10:44 PM, William Denniss <[email-masked]> wrote:
> 
> On Wed, Feb 3, 2016 at 10:27 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Hannes Tschofenig
> To: [email-masked] <mailto:[email-masked]>

---

From: Roland Hedberg <[email-masked]>
Date: Thu, 4 Feb 2016 09:00:37 +0000

> 3 feb 2016 kl. 00:48 skrev Phil Hunt <[email-masked]>:
> 
> 

I’ve (we’ve) had exactly this problem in the UMA use-case.
Which is just one example where an AS may have OAuth2 or OIDC parentage.
So, I support having different real values.

— Roland

---

From: Roland Hedberg <[email-masked]>
Date: Thu, 4 Feb 2016 09:01:29 +0000

+1

> 4 feb 2016 kl. 08:10 skrev Phil Hunt <[email-masked]>:
> 
> +1 for adoption.
> 
> www.independentid.com
> [email-masked]
>> On Wed, Feb 3, 2016 at 10:27 PM, Mike Jones <[email-masked]> wrote:

---

From: Justin Richer <[email-masked]>
Date: Thu, 4 Feb 2016 19:34:42 -0500

+1, if we define a webfinger/rel at all.

I would rather we just define the service discovery document, the thing that lives under .well-known.

 — Justin

> On Feb 4, 2016, at 4:01 AM, Roland Hedberg <[email-masked]> wrote:
> 
> +1
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 4 Feb 2016 16:40:15 -0800

I thought about this when doing the SCIM discovery document. Initially I only had cases for plain ./well-known.  But I found there are two types of clients. I decided later that mobile and web apps have different needs.

E.g. a mobile app might ask anonymously or on behalf of an already authenticated subject.  ./well-known works fine.

A web app that works on behalf of multiple users (e.g. is an OIDC client), might find that the answer varies based on the user acnt it wants to ask on behalf of.  The webfinger?rel=oauth&acnt:<someid> model works much better.

Phil

@independentid

> On Feb 4, 2016, at 4:34 PM, Justin Richer <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Feb 2016 22:03:00 -0300

I would personally be fine with just the .well-known discovery.

I think in the earlier thread I was trying to make the argument that webfinger discovery is going to be based on the API that you are looking for and not generic OAuth.

A generic OAuth rel per user doesn’t really make sense.   A client is looking for a OpenID Connect identity provider ,  a photo sharing service,  a calendar service etc.

Given the way UMA works by starting at the resource I would expect that a client would discover a medical records service and make a request to the API and get back a RPT token and location of the UMA server to get a AT.   I don’t quite know what good knowing the UMA server would be unless it supported discovery (Talked about I think) however that might be circular.

Let the protocols define how to use WebFinger and define the rel and we can pick up from there.

We should adopt the current dock as a starting point.  

John B.

> On Feb 4, 2016, at 9:34 PM, Justin Richer <[email-masked]> wrote:
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 6 Feb 2016 12:14:51 +0100

I think the service discovery document (describing all the endpoints and 
features of the AS) is a valid starting point. That's basically how we 
use the OIDC discovery in the OAuth context today at DT. We refer 
partners to the openid-configuration document. Putting the data relevant 
to OAuth under .well_known/oauth would be more reasonable from a OAuth 
developer's perspective (in my opinion).

We still have to learn, how clients really discover the location of this 
discovery document. We can come up with extensions for user id/resource 
service data based discovery at any time, if we

kind regards,
Torsten.

---

From: William Denniss <[email-masked]>
Date: Sat, 6 Feb 2016 11:19:44 -0800

It looks like discovery is useful for pure OAuth and OpenID Connect
providers alike.  What if we make *this* the primary document.  The OpenID
Connect metadata could be registered in the IANA registry here, and
potentially even revised to reference this doc.

There are benefits moving that work here, we would have an IANA registry
for metadata, and reach a broader audience.

As for the well-known path, given one was already established for similar
metadata and has already been rolled out by many, can we just grandfather
that and tolerate the name mismatch for the sake of avoiding duplication?

On Sat, Feb 6, 2016 at 3:14 AM, Torsten Lodderstedt <[email-masked]

> features of the AS) is a valid starting point. That's basically how we use
> the OIDC discovery in the OAuth context today at DT. We refer partners to
> the openid-configuration document. Putting the data relevant to OAuth under
> .well_known/oauth would be more reasonable from a OAuth developer's
> perspective (in my opinion).
>
> On Feb 4, 2016, at 4:01 AM, Roland Hedberg <[email-masked]> <[email-masked]> wrote:
>
> +1
>
>
> 4 feb 2016 kl. 08:10 skrev Phil Hunt <[email-masked]> <[email-masked]>:
>
> +1 for adoption.
>
> @[email-masked]
>
>
>
>
>  On Feb 3, 2016, at 10:44 PM, William Denniss <[email-masked]> <[email-masked]> wrote:
>
> On Wed, Feb 3, 2016 at 10:27 PM, Mike Jones <[email-masked]> <[email-masked]> wrote:
> From: OAuth [mailto:[email-masked] <[email-masked]>] On Behalf Of Hannes Tschofenig