Thanks John; incorporated your wording. http://github.com/daveman692/OAuth-2.0/commit/4c93341a85c70c0954945be636a8dce359fccb0f
On Tue, Mar 23, 2010 at 10:25 AM, John Panzer <jpan...@google.com> wrote: > On Sun, Mar 21, 2010 at 6:12 PM, Eve Maler <e...@xmlgrrl.com> wrote: >> >> On 21 Mar 2010, at 1:43 PM, David Recordon wrote: >> >> > The goal of the, "the authorization server advertises (such as via >> > documentation) the URIs of the following three endpoints" wording was to >> > allow for a discovery process that is defined separately from this spec. >> > Is >> > that unclear? Have other words to propose? >> >> So perhaps this wants to be a thin spec that can be combined with the >> OAuth core spec, if there's general interest in it. (In the UMA spec, we >> were already in the position of making up some XRD to describe a couple of >> WRAP endpoints, along with UMA endpoints and metadata. It would be nice to >> have a canonical version of the former, at the least.) > > So, > Minimally, perhaps the spec should say "advertises (such as via > documentation or discovery process beyond the scope of this document) the > URIs of the following three endpoints..." just to give people a heads up > that there may be external auto-discovery happening. > Beyond that, it might be nice to see if there could be a separate, svelte > auth discovery document of some sort, even if not part of the core spec. > Even something UMA-specific could serve as a good example for others. > My main worry is that SPs might start to think that they can do all kinds of > arbitrary things in their documentation to find the endpoints (register here > to generate the endpoints for your app, etc.) and thus go down a path that > means they can't ever participate in auto-discovery. Which is a fine path > if they explicitly decide they don't care about auto-discovery and interop, > but a poor path if they just didn't see the signs about the quicksand and > alligators and non-interoperability. > > _______________________________________________ > 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
