I agree, BUT.
I don't think it is very practical at this point. Defining new authentication
schemes (i.e. SAML assertion) means slower deployment due to lack of support in
existing applications. Reusing existing authentication schemes for a new set of
credentials has its own deployment challeng
Switching exclusively to token-based access for all APIs is one reasonable
approach. However this shouldn’t be required for services that just want to
support the user-delegation part of OAuth.
If Facebook used OAuth exclusively, then the only time a client_secret would be
used is when reques
In Facebook’s case, we would like to make our entire API accessible exclusively
via OAuth – including properties, metrics, etc. For our purposes, I think the
Client Credentials Flow
(http://github.com/theRazorBlade/draft-ietf-oauth/blob/master/draft-ietf-oauth.txt#L1869)
is sufficient. I prefer
Requests from a client app to collect an access token don’t need to use an
OAuth-specific client authentication mechanism.
A service that issues a client app with credentials (eg a client_id and
client_secret) is very likely to offer APIs specifically for clients, in
addition to APIs for clie
Agreed. Seems that consensus is no limit.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Monday, April 12, 2010 1:24 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Defining a maximum token length?
Unless the chairs decide otherwise, I'd say we're done
Relative doesn't require clock sync. It works well if there isn't a significant
delay in receiving the reply.
EHL
On 4/12/10 12:10 PM, "Torsten Lodderstedt" wrote:
What is the reason for using a relativ token lifetime specification?
SAML2 uses an absolute specification in datetime format (Not
Between language preferences, display configuration, and immediate check, I
think it might be worth to move that work to another draft. Timeline-wise, this
has the potential of slowing us down. I also fear getting what is now a pretty
simple spec much more complicated.
Anyone cares to try a fir
Unless the chairs decide otherwise, I'd say we're done discussing this... The
consensus is no limits but to offer guidance so that developers on both side
are aware of the need to communicate token sizes.
EHL
On 4/12/10 9:32 AM, "Allen Tom" wrote:
+1 on having no limits for the Access Token
On Apr 12, 2010, at 3:09 PM, Torsten Lodderstedt wrote:
> Am 12.04.2010 21:00, schrieb Luke Shepard:
If OAuth ever gets to the point where it replaces Basic auth in the
browser,
or used instead of other cookie-based authentication systems, it will gain
native browser support w
What is the reason for using a relativ token lifetime specification?
SAML2 uses an absolute specification in datetime format (NotOnOrAfter)
Am 07.04.2010 07:33, schrieb Brian Eaton:
On Tue, Apr 6, 2010 at 8:24 AM, Luke Shepard wrote:
Just curious, where did "duration" come from?
I hate to
Am 12.04.2010 21:00, schrieb Luke Shepard:
If OAuth ever gets to the point where it replaces Basic auth in the browser,
or used instead of other cookie-based authentication systems, it will gain
native browser support which will use the header exclusively. Until then, JS
code cannot make OAuth re
>> If OAuth ever gets to the point where it replaces Basic auth in the browser,
>> or used instead of other cookie-based authentication systems, it will gain
>> native browser support which will use the header exclusively. Until then, JS
>> code cannot make OAuth requests without other ways to send
As far as I know, OAuth 1.0a did not support bearer tokens.
Sure it did. Not cleanly (the RFC version fixed that) but since there is no
requirement to have a token secret, the PLAINTEXT method could easily be
used as a bearer token.
And what about the consumer secret? Isn't that req
Yes- I threw that in there as one way of handling an immediate response. We
will need the ability to do a background ping in an iframe, similar to
checkid_immediate in OpenID.
I agree that the parameters are functionally different ... on the other hand,
they are mutually exclusive (you won't ev
On Sat, Apr 10, 2010 at 1:02 PM, Chuck Mortimore
wrote:
> While I agree it’s a bit of an abusive practice, it is a pervasive one, and
> I’m worried about our ability to actually change the behavior of these
> platforms ( Mozilla is in the list as well ).
>
> So – it’s a bit of a trade off. I cer
On Fri, Apr 9, 2010 at 10:08 PM, Eran Hammer-Lahav wrote:
>
>
>
> On 4/9/10 1:58 PM, "Evan Gilbert" wrote:
>
> >
> >
> > On Fri, Apr 9, 2010 at 11:02 AM, Eran Hammer-Lahav
> > wrote:
> >>
> >>
> >>
> >> On 4/9/10 8:29 AM, "Evan Gilbert" wrote:
> >>
> >>>
> >>>
> >>> On Thu, Apr 8, 2010 at 11:50
+1 in general
Question about display=none - I missed this part before, and proposed a
different parameter (immediate=true) for the same purpose -
http://www.ietf.org/mail-archive/web/oauth/current/msg01694.html.
Anyone have thoughts on whether we should have a separate parameter for
immediate mod
+1 on having no limits for the Access Token length.
I fully acknowledge that shorter is better in the case where access
tokens are passed on the URL as query parameters (aka jsonp), there are
practical URL length limits. Bigger tokens consume more network resources,
which can be a severe issue
Hi Eran,
I'm not sure it is fair to include this request in with the "there's a lot of
things people want the core protocol to support", because this is something
that is available in 1.0a that we're considering taking away.
To be clear, I'm not as concerned with exact backwards compatibility (
Latest is always at:
http://github.com/theRazorBlade/draft-ietf-oauth
(xml is always up to date. txt and html when I can. Atom feed available)
---
I finished going over sections 1-5 which includes the overview, flows, refresh
method, and using tokens (including signatures). By finished I mean
Hi everyone,
In Section 3.4.4 there is a flow that requires repeated polling on the
part of the device client. Can someone explain why that is, and why the
device client can't simply make its desired operation known to the
authorization server and then block?
Thanks,
Eliot
___
Is there some other natural parameter limit in place from HTTP?
Eliot
On 4/12/10 11:23 AM, Anthony Nadalin wrote:
+1
*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Torsten Lodderstedt
*Sent:* Friday, April 09, 2010 11:57 PM
*To:* Eran Hammer-Lahav
*Cc:* OAuth
+1
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Friday, April 09, 2010 11:57 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Defining a maximum token length?
+1 no restriction, please
256 is much too short
Am 10.04.2010 07:16
23 matches
Mail list logo
