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 protected]> wrote: > > +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 protected]> wrote: >> >> +1 >> >>> 4 feb 2016 kl. 08:10 skrev Phil Hunt <[email protected]>: >>> >>> +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 >>> www.independentid.com >>> [email protected] >>> >>> >>> >>> >>> >>>> On Feb 3, 2016, at 10:44 PM, William Denniss <[email protected]> wrote: >>>> >>>> +1 for adoption of this document by the working group >>>> >>>> On Wed, Feb 3, 2016 at 10:27 PM, Mike Jones <[email protected]> >>>> 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 >>>> >>>> -----Original Message----- >>>> From: OAuth [mailto:[email protected]] On Behalf Of Hannes Tschofenig >>>> Sent: Tuesday, January 19, 2016 3:49 AM >>>> To: [email protected] >>>> 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 >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
