Yes. The user is delegating access to the browser. EHL
On 5/20/10 9:05 AM, "Dick Hardt" <dick.ha...@gmail.com> wrote: The image can be protected by both. Do you expect OAuth to be used with user present in the browser? On 2010-05-17, at 11:20 PM, Eran Hammer-Lahav wrote: Why can't an image be protected with both Basic and OAuth? In this case the browser is the OAuth client. EHL From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Sunday, May 16, 2010 11:38 AM To: Eran Hammer-Lahav Cc: Evan Gilbert; OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid Not sure if you intended this, but you are mixing user present and user not present access control. I do NOT think we want OAuth protected images to be the same as Basic auth protected images. I do think OpenID protected images and Basic auth are similar. With OAuth today, the user has granted explicit permission at a particular resource, not any resource the user may have access to. -- Dick On Thu, May 13, 2010 at 9:30 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: Today when I cut/paste a URI of an image using Basic auth, the browser knows exactly what to do. I want to do the same with an OAuth-protected image. Saying that there aren't standards API out there to benefit from this is incorrect. There are plenty. This is complete discovery for the authentication layer. The rest doesn't belong here, the same way this doesn't belong as part of the API specification. EHL From: Evan Gilbert [mailto:uid...@google.com] Sent: Thursday, May 13, 2010 9:16 AM To: Eran Hammer-Lahav Cc: Manger, James H; OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: You are trying to match a mechanism designed for automatic discovery with a system designed to require paperwork. It sounds like for your use cases, you will not be using this optional parameter and just document how to use your API (i.e. hardcode your security setup and API format). I'm saying it should be a fully automatic discovery or use paperwork. Having an API return valid URL prefixes to send the token to without having an API to determine the actual URLs you send tokens to seems odd. The whole point of this is that the developer isn't involved. The library takes care of everything. All the developer does is ask to get a protected resource. The library will check if it already has a valid token for that resource (based on the security restrictions provided by the sites parameter, and the scope requirements - two very separate things). This is an incomplete mechanism for automatic discovery. How does the developer find out where to ask for the protected resource in the first place? So yes - if your developers have plenty of stuff to hardcode already, this adds little value. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Evan Gilbert Sent: Thursday, May 13, 2010 9:00 AM To: Manger, James H Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid On Wed, May 12, 2010 at 11:52 PM, Manger, James H <james.h.man...@team.telstra.com> wrote: Evan, > The key point is that this discovery covers a lot of the same grounds as the > sites parameter, and it's hard to define semantics around a sites parameter > without understanding the semantics of scopes and API endpoints. I strongly disagree. The semantics are crystal clear: "Here is a token. It is INSECURE to send it anywhere not in this list." These semantics are useful regardless of what the API does, how the client is using it, or how much (or how little) the client knows about the API. To expand - it's hard to define *useful* semantics around a sites parameter without understanding the semantics of scopes and API endpoints. Yes, you can define crystal clear semantics, but these are not useful unless they work well with the way developers figure out the endpoints to call APIs. > Clients need to [know] more about these links (at least the response format). That knowledge comes from other standards (HTML, Atom, wiki of rel values...) and is totally independent of whether a token should or should not be sent. In our use cases, clients almost always need to know more about the API: - How to call directly - we have no API endpoints that are only arrived at by links - Response format of the data > The mechanism they use to find out about these links - documentation, > discovery, data returned with token request - could also provide the > information about whether a token should be sent to a particular API. Could, but shouldn't and doesn't in practise. It is much much better to have the information about how to use a token securely delivered at the same time & place as receiving that token, and with minimal assumptions about how much the client apps knows about the service. So why wouldn't we return a list of specific API endpoints instead of a "sites" parameter? Developers are going to call the APIs endpoints that they know about. If there is a conflict between this and the sites parameter, what should they do? For example, if facebook returns a sites parameter "https://unknown.facebook.com/";, do we think the developer is going to not try to use the access token on https://graph.facebook.com/ <https://graph.facebook.com/*> ? Separating the concept of sites from API endpoints feels like a bad idea. Discovery / docs will give you a list of URLs where you should send tokens. The "sites" parameter will give you a list of URLs where you can send tokens. This is redundant, and will lead to developers / libraries not respecting the sites parameter. If developers / libraries don't respect it, then the service can't rely on it for enforcing security. Another note: Where do we anticipate clients storing the sites parameter in the User-Agent flow? Right now the access token can be set as an HTTP cookie by the client. Do we expect them to set a separate "sites" cookie and respect this on their server when making requests? This seems complicated. > I should be more concrete about the use cases I see. Let's assume there's an > API where there are two endpoints, each with an associated permission > - contacts.list permission -> > http://contacts.serviceprovider.com/contacts/list > - calendar.get permission -> http://calendar.serviceprovider.com/calendar/get > > If the response to an authorization request includes the authorized scopes > (contacts.list, calendar.get), then the "sites" parameter is redundant. I'll admit that "sites" is redundant if a client has *perfect* knowledge about a service, but so is pretty much any standard at that point. Consider a generic search spider tool that you point at http://calendar.serviceprovider.com/calendar/get. It can do its job with no knowledge about what "calendar.get" means -- but it still needs to know (as it spiders along) when it is safe to expose the token. How does the generic search spider know to call to http://calendar.serviceprovider.com/calendar/get in the first place? -- James Manger _______________________________________________ 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
