I don't recall any discussion at the level of detail that Torsten is asking about.
My inclination would be the Client would include the what was returned in WWW-Authenticate in the access request call. On Tue, Jun 1, 2010 at 11:47 AM, Peter Saint-Andre <[email protected]>wrote: > We discussed this a bit at the interim meeting, but I don't think we > came to any consensus. > > On 6/1/10 12:46 PM, Torsten Lodderstedt wrote: > > Is there anyone who can answer my questions? > > > > Am 30.05.2010 17:56, schrieb Torsten Lodderstedt: > >> I have some questions regarding the WWW-Authenticate header's "scope" > >> attribute. > >> > >> The spec states > >> > >> "The "scope" attribute is a space-delimited list of URIs (relative or > >> absolute) indicating the required scope of the access token for > >> accessing the requested resource." > >> > >> Which of the scope URIs are required for accessing the resource > >> server, at least one or all of them? > >> > >> How is an interoperable OAuth2 client supposed to use this atttribute? > >> Shall the client copy the content into the scope parameter of a > >> subsequent authorization request? > >> > >> What is the envisioned behavior if a client seeks for access > >> authorization to different resources, which happen to rely on the same > >> authorization server? Is the client allowed to combine the scope > >> attributes from the WWW-Authenticate header of both resources in a > >> single authorization flow? This would allow the client to obtain > >> authorization with a single flow. From my point of view, reducing the > >> number of authorization flows would improve user experience. > >> > >> How is as equivalence of authorization servers determined (token-uri, > >> user-uri, both)? > >> > >> regards, > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
