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
On 13 April 2012 12:18, Mike Jones michael.jo...@microsoft.com 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
On 12 April 2012 17:51, Mike Jones michael.jo...@microsoft.com 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
On 15 March 2012 17:31, Zeltsan, Zachary (Zachary)
zachary.zelt...@alcatel-lucent.com 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
On 14 March 2012 20:21, Hannes Tschofenig hannes.tschofe...@gmx.net 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
On 18 December 2011 17:22, Doug Tangren d.tang...@gmail.com wrote:
On Sun, Dec 18, 2011 at 12:05 PM, Melvin Carvalho melvincarva...@gmail.com
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
On 11 December 2011 11:30, Leif Johansson le...@mnt.se wrote:
5 dec 2011 kl. 00:34 skrev Blaine Cook rom...@gmail.com:
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
On 4 December 2011 02:26, Mike Jones michael.jo...@microsoft.com 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
On 2 December 2011 03:20, Barry Leiba barryle...@computer.org 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
+1. This is good.
On 19 November 2011 16:41, Eran Hammer-Lahav e...@hueniverse.com 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
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
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
Accepted into the tracker. Thanks, Brian!
b.
On 4 January 2011 08:26, Brian Campbell bcampb...@pingidentity.com 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
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
On 15 July 2010 15:59, Justin Richer jric...@mitre.org 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
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
+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
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 jric...@mitre.org wrote:
D
On Thu, 2010-07-08 at 12:29 -0400, David Recordon wrote:
I'm honestly trying to
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
On 28 May 2010 02:21, Brian Eaton bea...@google.com 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
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
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]
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
chair hat
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
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
25 matches
Mail list logo
