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/>phil.h...@oracle.com <mailto:phil.h...@oracle.com> > On Feb 2, 2016, at 3:02 PM, Brian Campbell <bcampb...@pingidentity.com> 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 > <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> 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, see >> https://tools.ietf.org/html/draft-jones-oauth-discovery-00 >> <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 >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <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
