The old AOL Blogs API, which used AOL's OpenAuth service, provided a url= parameter on WWW-Authenticate: challenges:
dev.estage.aol.com/aolblogs_api#mozTocId815750 <http://webcache.googleusercontent.com/search?q=cache:VD8dYmqAaREJ:dev.estage.aol.com/aolblogs_api+AOL+OpenAuth+401+response+WWW-Authenticate&cd=9&hl=en&ct=clnk&gl=us> - If authorization fails, a 401 response is returned with a WWW-Authenticate: header providing additional details. WWW-Authenticate: OpenAuth realm="AOLBlogs", status="status", msg="message", url="url" This is from 2007 ;). On Tue, Apr 27, 2010 at 11:49 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Am 24.04.2010 02:05, schrieb Brian Eaton: > > On Thu, Apr 22, 2010 at 6:11 PM, Manger, James H >> <james.h.man...@team.telstra.com> wrote: >> >> >>> We mustn't drop advertisements (details in 401 responses). >>> We mustn't drop the goal of a standard for interoperability. >>> >>> >> I share the goals, I just don't think that a specification is the way >> to get there. I think working examples in the wild would help >> enormously. >> >> >> >>> Defining a scope field in a 401 response is the novel aspect that “might >>> not actually work”. Allowing a 'scope' query parameter in authz URIs is be >>> quite separate. >>> >>> >> Yeah, I agree with that analysis. >> >> Though I don't know of any providers that are returning authorization >> URLs in 401 responses right now. That's novel, too. >> >> >> > > That's novel, yes. But I think no one did it before because there was no > need to do so. BASIC and DIGEST don't require authorization endpoint > coordinates. SPNEGO/Kerberos would be a candidate because of its > architecture, but it uses the standard Kerberos mechanisms (config or > DNS-based discovery via SRV records). > > I think there is a need for a standardized way of authorization server > discovery. Using the WWW-Authentication header is better than nothing from > my point of view. > > Alternatively, resource servers could publish their supported > authentication servers via XRD or a similar mechanism. The authorization > server in turn could publish its endpoints (and capabilities) the same way. > > regards, > Torsten. > > > _______________________________________________ > 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
