Yep. I'm trying to remove the need for a more complex discovery. EHL
On 4/3/10 3:35 AM, "Torsten Lodderstedt" <tors...@lodderstedt.net> wrote: > I've just seen, the current draft already specifies an attribute > "authorization-uri" for the WWW-Authenticate header. Is this attribute > intended for announcing the authorization servers endpoint? > >> I don't think the example implies discovery. As far as I understood, >> it just uses the same addresses for both protected resource and >> authorization server. This might work for some deployments, it won't >> work for installation with a single authorization server authorizing >> access to multiple resources with different adresses. >> >> I like the idea of using the protected resources realm as resource >> specification in the authorization server requests. To enhance the >> idea we need some kind of endpoint discovery. The simplest way would >> be to include another parameter in the WWW-Authenticate response >> indicating the authorization servers endpoint, e.g. >> >> HTTP/1.1 401 Unauthorized >> WWW-Authenticate: OAuth realm='example', >> endpoint='authorization.example.com' >> >> According to http://www.ietf.org/rfc/rfc2617.txt (Basic/Digest Authn >> Spec) this should be a legal usage of the WW-Authenticate header. An >> example of a WWW-Authenticate header for Digest authentication is: >> >> WWW-Authenticate: Digest realm="testre...@host.com", >> qop="auth,auth-int", >> nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", >> opaque="5ccc069c403ebaf9f0171e9517f40e41" >> >> regards, >> Torsten. >>> Presumably, the realm was used to discover the token issuance endpoints. >>> Why wouldn't the discovered URL of the access token endpoint dictate >>> realm, and why can't the realm then be implicit beyond discovery? >>> >>> -----Original Message----- >>> From: Eran Hammer-Lahav<e...@hueniverse.com> >>> To: OAuth WG<oauth@ietf.org> >>> Subject: [OAUTH-WG] Scope using Realm idea >>> Date: Fri, 2 Apr 2010 09:18:36 -0700 >>> >>> This is half baked but I wanted to get people's reaction: >>> >>> Clients tries accessing a resource with or without an access token: >>> >>> GET /resource/1 HTTP/1.1 >>> Host: server.example.com >>> >>> The server replies with: >>> >>> HTTP/1.1 401 Unauthorized >>> WWW-Authenticate: OAuth realm='example' >>> >>> Clients requests an access token (using the client credentials flow) and >>> includes the requested realm (line breaks for display purposes): >>> >>> POST /access_token HTTP/1.1 >>> Host: server.example.com >>> >>> client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM& >>> mode=flow_client&realm=example >>> >>> The server issues a access token capable of accessing the resource >>> realm. >>> >>> This means one new parameter on the request side which is already >>> baked into >>> the 401 response in a standard way. >>> >>> Thoughts? >>> >>> EHL >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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
