Hi all,
Now that the Easter holiday is over, please review the following
revised OAuth charter and provide feedback by May 5th (one week from
today). Thanks!
Description of Working Group
The Open Web Authentication (OAuth) protocol allows a user to grant
a third-party Web site or application ac
From my chair-seat, Barry's interpretation matches mine. Having
carefully reviewed Eran's revised text vis-a-vis the proposal from
Anthony et al., it seems like the concerns are addressed without
forcing the use of any specific mechanism to maintain state, which is
commensurate with the approach to
+1. This is good.
On 19 November 2011 16:41, Eran Hammer-Lahav wrote:
> We had a long discussion about what to use for the numerical component of
> the nonce string. I would like to suggest we use:
>
>
>
> nonce
>
> REQUIRED. A unique string generated by the client to allow the
>
>
On 2 December 2011 03:20, Barry Leiba wrote:
> Stephen is thinking that code will be reused. Perhaps there'll be a
> limited number of coded toolkits, and their code will be used to
> implement various authorization servers, etc. That's the way a lot of
> Internet code is done today. In that ca
On 4 December 2011 02:26, Mike Jones wrote:
> I strongly object to a mandatory-to-implement clause for the MAC scheme.
> They are unnecessary and market forces have shown that implementers do not
> want or need this kind of an authentication scheme.
I'd say that Twitter, Flickr, Dropbox and do
On 11 December 2011 11:30, Leif Johansson wrote:
>
> 5 dec 2011 kl. 00:34 skrev Blaine Cook :
>
> Oauth 1.0a mac and 2.0 mac are not the same thing. Yours is an argument for
> backwards compat I think.
The syntax is different / better, the spec is cleaner, but they
specify e
On 18 December 2011 17:22, Doug Tangren wrote:
>
> On Sun, Dec 18, 2011 at 12:05 PM, Melvin Carvalho
> wrote:
>>
>> Is this kind of flow possibly with OAuth 2.0, and if so whose
>> responsibility is it to maintain the list of agents than can access
>> the resource?
>
> The scope parameter fulfill
On 14 March 2012 20:21, Hannes Tschofenig wrote:
> So, here is a proposal:
>
> [Editor's Note: New work for the group. 5 items maximum! ]
>
> Aug. 2012 Submit 'Token Revocation' to the IESG for consideration as a
> Proposed Standard
> Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for
On 15 March 2012 17:31, Zeltsan, Zachary (Zachary)
wrote:
> ... Considering OpenID Connect as a motivating use case for OAuth, SWD is
> the one spec that would then be missing for this OAuth use case.
I worry that bringing OpenID Connect into OAuth (rather than building
upon OAuth) will have det
On 12 April 2012 17:51, Mike Jones wrote:
> Thanks for asking these questions Hannes. I'll first provide a brief
> feature comparison of Simple Web Discovery and WebFinger and then answer
> your questions.
>
> FEATURE COMPARISON
>
> RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: SWD returns th
On 13 April 2012 12:18, Mike Jones wrote:
> Hi Blaine. I must admit, I’m pretty surprised by the tone of your
> reply. I’ll say up front that I have absolutely no problem with anyone
> disagreeing with me on a technical or tactical basis. If you think I’m
> wrong, have at it.
>
> ** **
>
That's a tricky question - maybe one google can help answer? There are a
bunch of projects using webfinger, including status.net, ostatus in
general, diaspora, unhosted, freedombox(?), and I'm sure others, but I have
no idea how that translates into actual users or profiles.
Gmail, aol, and yahoo
I disagree that the current spec is a good starting point - the issues I've
raised have been ignored, and the spec is now much more complicated from
both sides of the implementation fence.
On May 7, 2012 3:17 PM, "Paul E. Jones" wrote:
> Walter,
>
> I'm not sure what the full set of issues will
On 8 May 2012 16:55, Hannes Tschofenig wrote:
> The discussions around XML vs. JSON are unfortunately also hiding the real
> important discussion, namely privacy.
>
> We are actually building, without further thinking about it, a mechanism that
> offers worse privacy properties compared to what
One of the things that's been a primary focus of both today's WG call
and last week's call is what are the specific use cases for
signatures?
- Why are signatures needed?
- What do signatures need to protect?
Let's try to outline the use cases! Please reply here, so that we have
a good idea of wh
Hi all,
just a heads up that events have conspired such that I won't be at the
meeting in person, but will be participating via webex. Peter will be
present, and with his forthcoming appointment as Apps Area Director,
will be imbued with the moderating powers of ten ordinary Chairs (as
if he wasn'
Hi all,
Hannes and I have discussed the results of the WG meeting, and while
there was a lot of good discussion that happened, it seems like the
next step for the WG is to buckle down and produce a stable draft that
incorporates all the various proposals, in particular WRAP and OAuth
1.0a. David
My take on this is that MUSTs MAY be ignored. ;-)
To echo John's concerns here, the worst-case scenario is that client
libraries implement "no SSL present" as a gentle reminder warning with
a flag (possibly the default) to disable those HTTPS warnings. Clients
that behave in that way should be fla
This is a reminder that feedback that you'd like to see incorporated
into the -00 working group draft is due by 4/19 (Monday).
Please submit comments as a separate message to this list. Thanks!
b.
(see recent posts to the list and
http://www.ietf.org/mail-archive/web/oauth/current/msg01957.html
This is a call for consensus on accepting Eran's latest OAuth draft,
draft-hammer-oauth2 [1] as a working group item. Assuming no
objections by end-of-day Tuesday, April 22nd, this draft will be
promoted to an active working group document on Wednesday, April 23rd.
b.
[1] http://datatracker.ietf.
On 23 April 2010 17:01, Peter Saint-Andre wrote:
> On 4/23/10 8:05 AM, Prateek Mishra wrote:
>> Do you mean April 29 (Thu) and April 30th (Fri)?
>
> Clearly yes.
lol, neither. I think I managed to look at a 2009 calendar somehow,
and travel has left me completely unaware as to the current date.
Hannes and I are currently working on preparing an agenda for next
week's meeting. In addition to the two issues Eran has open for
comments on the list, we would like to solicit open issues from the
community.
Thanks to the incredible efforts that Eran and everyone else who has
contributed recentl
On 28 May 2010 02:21, Brian Eaton wrote:
> OAuth 1.0 was unusual in that it required that the server match a hash
> of the URL, rather than the real URL. It's an extra layer of
> indirection and complexity. It doesn't improve security.
To be more precise, OAuth 1.0 required that the server matc
I agree with Dick that the scope should remain out of scope for OAuth.
;-) Having a shared parameter here gives the illusion of
interoperability, but because there's no common understanding of
permissible scopes, there's no way to guarantee that any given
client-server pair could expect to produce
A, BUT I will be unable to attend Monday-Wednesday. I'll be around
Thursday / Friday to work on issues and so forth if others will be
there, too.
b.
On 8 July 2010 17:43, Justin Richer wrote:
> D
>
> On Thu, 2010-07-08 at 12:29 -0400, David Recordon wrote:
>> I'm honestly trying to decide myself
I don't claim to fully grok what the current state of the various
proposals are regarding the user agent flow, but fundamentally,
shouldn't we be aiming to replicate what Twitter and Facebook are
already doing?
We've already moved towards JSON as a standard format, why not go all
the way and manda
+1 on "like a password", or something similar-and-meaningful because
that's exactly how it's being used here. Pre-shared key, shared
secret, etc, would be fine. Keep in mind that authentication *will be
done* using the bearer token, and the bearer token alone.
An OAuth token is unlike capabilities
On 13 July 2010 20:31, John Kemp wrote:
> Where is that specified? Is that required for all implementations?
It's not specified - I was referring to your earlier comments:
> In the "bearer token" case (and even over SSL unless client certs are used),
> the
> token clearly SHOULD NOT be used as
On 15 July 2010 15:59, Justin Richer wrote:
> +1 on OAuth2 header, and I also want to see oauth2_token in URI and form
> parameter methods.
>
> 1.0 clients will talk to systems that support both oauth2 and oauth1
> simultaneously. Most likely on the same PR endpoints as well. Since the
> protocols
Over the past few weeks, the working group debated the issues around
the introduction of signatures and the structure of the specification.
The working group seems to endorse the proposal to split the current
specification into two parts: one including section 5 (bearer token)
and the other includi
sfully served as an editor for several standards
>> specifications, including the OASIS IMI specification and related SAML token
>> profiles, the OpenID PAPE specification, and (some time ago), the POSIX
>> Threads standard.
>> >
>> > --
Accepted into the tracker. Thanks, Brian!
b.
On 4 January 2011 08:26, Brian Campbell wrote:
> Thanks Peter. I did update the draft and submit it with a
> draft-ietf-oauth- prefix. The I-D submission summary page for it is at
> https://datatracker.ietf.org/idst/status.cgi?submission_id=28905
>
>
DO NOT REPLY TO THIS EMAIL.
To Eran's point, before reaching the end of this thread after limited
access to email over the weekend, I was going to shut this thread down
anyways.
I'm not going to issue a call for consensus on this issue, because I
don't believe anyone on the list (except for a s
2010/1/9 John Kemp :
> On Jan 8, 2010, at 9:15 PM, Eran Hammer-Lahav wrote:
>
> What is the actual reasoning behind this change? I don't understand why we
> would suddenly now decide to make some whole class of implementations
> non-conforming, even if there were only few deployments?
Eran did a
OAuth WRAP is very similar to cookies as deployed by major vendors.
Google has just switched to HTTPS-by-default for all GMail
sessions[1], and my understanding (per [2]) is that access to
authenticated sessions (i.e., full GMail or Google Docs access versus
just displaying "b...@gmail.com" on the
2010/1/14 Eran Hammer-Lahav :
> QUESTION: Do you prefer:
>
> A. Directly processing the HTTP request into a base string for signing
> (draft-hammer-oauth style).
> B. Treating the request as an API call with form-encoded parameters (OAuth
> 1.0 style).
> C. Converting the request into a normalized
2010/1/14 Blaine Cook :
> 2010/1/14 Eran Hammer-Lahav :
>> QUESTION: Do you prefer:
>>
>> A. Directly processing the HTTP request into a base string for signing
>> (draft-hammer-oauth style).
>> B. Treating the request as an API call with form-encoded para
2010/1/14 Eran Hammer-Lahav :
> QUESTIONS: How do people feel about this? What are some other advantaged and
> disadvantages of this approach?
The disadvantages you outlined massively outweigh the advantages. I've
had a persistent search for OAuth on Twitter for some time now, and
anecdotally, peo
I've started a wiki page here:
http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthFeatureMatrix
to pull in the features people think are important, and give us both
some way of collecting that data over time and expressing what's
present or missing from each protocol & proposal. Despite being call
Hi all,
Below is a very rough agenda for Thursday's interim meeting. Your
feedback is very welcome to improve this agenda, either on the list or
during the meeting ("agenda bashing").
Peter and I have included a request for a scribe; if anyone would like
to volunteer beforehand, we'd be very grat
40 matches
Mail list logo
