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/ ? > > 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
