from my understanding, the assertion you explained in your scenario
represent the authorization of end-users (not client applications) to
access feeds. Thus I see them as a kind of user credentials and would
send them as request parameter. Authorization headers will be used for
client authentic
David,
> Why would we support bearer tokens over HTTP?
> Is someone planning to implement this?
Because the cookies-over-HTTP ~equivalent is widely used.
The spec does say SHOULD NOT, but also explicitly talks about how to do it.
the spec suggests limited scope and lifetime -- limited scope impli
Why would we support bearer tokens over HTTP? Is someone planning to
implement this?
On Thu, May 13, 2010 at 8:25 PM, Manger, James H <
james.h.man...@team.telstra.com> wrote:
> Some APIs (and certainly lots of web sites) use a mix of HTTPS and HTTP
> resources. Using the same bearer token for b
Hey everyone,
I wrote up a post giving detail about exactly what Facebook has and has not
implemented from the OAuth 2.0 spec (with plenty of supporting links):
http://www.sociallipstick.com/?p=239
In summary:
- Current as of v0 of the draft. I think we are mostly current with v4
(although I
Some APIs (and certainly lots of web sites) use a mix of HTTPS and HTTP
resources. Using the same bearer token for both sets of resources limits
security of the HTTPS interactions to the insecurity of the HTTP ones.
A better approach is to use separate tokens. Exposure of a token used on HTTP
do
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Greg Brail
> Sent: Thursday, May 13, 2010 6:57 PM
>Eran or whoemever is so empowered were to choose
No one is empowered to choose. We need to keep at it until we reach consensus,
but some
I'm sorry that I'm late on this but for what it's worth:
Server Response Format: I prefer A (form-encoded only). It's the simplest
solution that requires the least amount of client-side technology. JSON is
too complex a spec for simply encoding a set of flat key-value parameters
when where is alre
On Thu, May 13, 2010 at 7:43 PM, Eran Hammer-Lahav wrote:
> Can you give a reason why you are objecting to C.
>
As I just wrote:
> My objection to C was that your examples were buggy.
I don't think servers or clients will get XML, JSON, and form-encoded
right without taking on a lot of 3rd party
Evan,
> we have no API endpoints that are only arrived at by links
This doesn't sound very web-friendly. Your APIs don't have to follow a
web-style, but an IETF spec should support web-style APIs.
I am a bit surprised with your statement as a whole lot of Google APIs do have
API endpoints arri
Can you give a reason why you are objecting to C.
EHL
> -Original Message-
> From: Robert Sayre [mailto:say...@gmail.com]
> Sent: Thursday, May 13, 2010 4:27 PM
> To: Eran Hammer-Lahav
> Cc: Yaron Goland; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respo
On Thu, May 13, 2010 at 4:54 PM, Manger, James H <
james.h.man...@team.telstra.com> wrote:
> Evan,
>
> > we have no API endpoints that are only arrived at by links
>
> This doesn't sound very web-friendly. Your APIs don't have to follow a
> web-style, but an IETF spec should support web-style APIs
Three things about draft-05's new format parameter.
1. Error Response:
http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.3.2.2
Presumably, the error response format should reflect the format
parameter passed by the client.
Proposed Text (wording taken from
http://tools.ietf.org/html/dr
I'm interested in the possibility of requiring clients to use
cryptographic tokens.
Context: I'm writing a WordPress plugin to handle OAuth 2.0
authentication. Small one-off WordPress sites (probably on a shared
host) likely cannot use SSL. Such a site would necessarily be
non-compliant because
On Thu, May 13, 2010 at 6:12 AM, Torsten Lodderstedt
wrote:
>
>>
>> Sure, to give one example, I would make the device flow a separate
>> spec immediately. That seems only distantly related to other things in
>> the spec, and may not be really necessary by the time the standard
>> matures.
>>
>
>
On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav wrote:
> There is clearly no consensus for either A or B. There was mostly no
> objection to C,
> and the reason given by most of those who objected was client complexity with
> the current proposal solves.
My objection to C was that your examp
There is clearly no consensus for either A or B. There was mostly no objection
to C, and the reason given by most of those who objected was client complexity
with the current proposal solves.
Weak consensus means that the option has some support and little objection. If
those who had something
Why would there be any use experience at all?
1. An OAuth client gets a refresh token in the context of http://example.com
2. While interacting with http://example.com the OAuth client sees a link to
http://foo.com and has reason to believe that foo.com is actually part of
example.com but isn'
But in federation scenarios the client credentials are an assertion.
For example, Microsoft has a service called Dallas that lets entities purchase
access to proprietary data feeds. A common scenario we run into with Dallas is
that a company will purchase access to a feed for its employees. But
I went through and counted all the votes I could find in the mail archive (I
have reproduced the results below). 8 people explicitly stated a preference for
A or B (of those 4 explicitly stated they don't want C). Only 3 people voted
for C as their first choice.
Even if we bunch together peopl
Two snippets from the emails below:
> > You mean token format? OAuth defined the token as opaque so that
> would be counter-productive.
My comment on that comment:
"opaque" for oauth could mean that oauth does not handle certain
types of tokens specially.
I think this is not an a
Changes:
o Corrected device example.
o Added client credentials parameters to the assertion flow as OPTIONAL.
o Added the ability to send client credentials using an HTTP authentication
scheme.
o Initial text for the "WWW-Authenticate" header (also added scope support).
o Chan
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Protocol
Author(s) : E. Hammer-Lahav, et al.
Filename: dr
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Monday, May 10, 2010 12:12 PM
> >> 3.6.1.1. End-user Grants Authorization
> >>
> >> Why not call the "code" Parameter "verification_code"? It's called
> >> verification code in the text.
> >>
> > L
The flow is not SAML-specific.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Prateek Mishra
> Sent: Thursday, May 13, 2010 10:15 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow
>
> S
SAML 2.0 assertions can represent a variety (very large) of
relationships between the presenter, issuer, subject, means of
confirmation and so on and so forth.
So representing multiple identities - i am server foo but I am acting
for joe - is not very difficult.
We can profile these versus add
Thanks to those who participated!
Some conclusions:
> 1. Server Response Format
>
> After extensive debate, we have a large group in favor of using JSON as the
> only response format (current draft). We also have a smaller group but with
> stronger feelings on the subject that JSON adds complexi
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 authenti
On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav 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
Thanks.
Am 13.05.2010 um 18:02 schrieb Eran Hammer-Lahav :
Will be added to -05.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf
Of Brian Eaton
Sent: Thursday, May 13, 2010 8:50 AM
To: Chuck Mortimore
Cc: oauth@ietf.org
Subject: Re:
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).
The whole
Will be added to -05.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Thursday, May 13, 2010 8:50 AM
> To: Chuck Mortimore
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Fl
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 semantic
On Thu, May 13, 2010 at 8:26 AM, Chuck Mortimore
wrote:
> Our plan is to treat SAML assertions passed over the assertion flow as
> bearer assertions, so I believe we have everything we need contained within
> the assertion (issuer + audience + signature). That being said, if we want
> this to be
Our plan is to treat SAML assertions passed over the assertion flow as bearer
assertions, so I believe we have everything we need contained within the
assertion (issuer + audience + signature). That being said, if we want this to
be an extensible flow, not all assertion formats will be so trans
Torsten,
> What about refresh token revocation/deletion?
HTTP already has a method to do this: DELETE
It just needs each token to have a URI.
Tokens (almost) already have URIs -- its just not immediately obvious because
the URI has to be built from a common token endpoint and a refresh_token.
Am 13.05.2010 13:05, schrieb Paul Madsen:
Torsten, have you thought about the relevance of the for
identifying the client?
Identify if not authenticate.
Thanks for your advice.
I would not expect the issuer to by the client in that game. In my
opinion a client could be a website, which ob
Torsten, have you thought about the relevance of the for
identifying the client?
Identify if not authenticate.
On 5/13/2010 6:38 AM, Torsten Lodderstedt wrote:
In my perception, we reached consensus in the thread "Autonomous
clients and resource owners (editorial)" that the assertion flow
s
OAuth currently focues on the issuance and usage of tokens.
What about refresh token revocation/deletion?
Several mobile apps today use long-living tokens as a means to log in to
services. They typically also offer a button to log-off/log-out, which
cause the app to delete the token from the d
In my perception, we reached consensus in the thread "Autonomous clients
and resource owners (editorial)" that the assertion flow should support
clients acting on behalf of users, not only autonomous clients.
The specification currently states "This flow is suitable when the
client is acting a
Am 13.05.2010 02:41, schrieb Robert Sayre:
On Wed, May 12, 2010 at 7:37 PM, Eran Hammer-Lahav wrote:
Oh, I wouldn't expect it to stop. The group has a bunch of unrelated stuff
grouped into one document. There seems to be consensus to do that, but it
still runs counter to the conventio
40 matches
Mail list logo
