Recordon, [EMAIL PROTECTED], Six Apart
- Dirk Balfanz, [EMAIL PROTECTED], Google
- Joseph Smarr, [EMAIL PROTECTED], Plaxo
- Yariv Adan, [EMAIL PROTECTED], Google - Allen Tom, [EMAIL PROTECTED],
Yahoo
- Josh Hoyt, [EMAIL PROTECTED] , JanRain
Initial Editors:
- Dirk Balfanz, [EMAIL
On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom [EMAIL PROTECTED] wrote:
Dirk Balfanz wrote:
I don't think this is true - I believe the realm is sufficient. Let me try
and explain. (We'll assume registered consumers.) On the approval page, we
need to identify the consumer. In its current form
from consumer key to (one) realm should
suffice.
Dirk.
Sent from a mobile device.
On Nov 13, 2008, at 3:58 PM, Dirk Balfanz [EMAIL PROTECTED] wrote:
On Thu, Nov 13, 2008 at 12:46 PM, Allen Tom [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi Yariv,
In the registered consumer case
, Dirk Balfanz [EMAIL PROTECTED] wrote:
On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Dirk Balfanz wrote:
I don't think this is true - I believe the realm is sufficient. Let me
try and explain. (We'll assume registered consumers.) On the approval
I don't want to put parameters into the protocol that aren't necessary.
So far, I've heard one argument for adding the consumer key in the
association request: to give a hint to the authorization UI as to whether or
not the consumer is authorized to request the scope passed in the
Yes, but as Breno said, the OAuth spec does not currently have a concept of
scope, however, the Consumer Key is definitely part of the spec. It would
seem to be more generally useful for a Consumer to signal Consumer Key,
rather than signaling scope, as many SPs need to know the CK, but not
needed to assert
auth responses.
So that's why SPs may need the CK in order to display the Approval page.
Make sense?
Allen
Dirk Balfanz wrote:
Need to know the CK for what? What purpose would hinting at the CK serve
(since it wouldn't prove ownership)? And don't say scope
Ok, new spec is up:
http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html
Dirk.
On Mon, Nov 17, 2008 at 5:40 PM, Dirk Balfanz [EMAIL PROTECTED] wrote:
[+Brian Eaton]
On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom [EMAIL PROTECTED] wrote:
Sadly
is currently
reading.
Dirk.
On Tue, Nov 18, 2008 at 11:56 AM, Dirk Balfanz [EMAIL PROTECTED] wrote:
Ok, new spec is up:
http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html
Dirk.
On Mon, Nov 17, 2008 at 5:40 PM, Dirk Balfanz [EMAIL PROTECTED
On Tue, Nov 18, 2008 at 6:58 PM, Allen Tom [EMAIL PROTECTED] wrote:
Dirk Balfanz wrote:
Ok, new spec is up:
http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html
Hi Dirk,
It doesn't look like the hybrid spec changes the OpenID association
On Tue, Nov 18, 2008 at 10:04 PM, Breno de Medeiros [EMAIL PROTECTED]wrote:
On Tue, Nov 18, 2008 at 10:00 PM, Dirk Balfanz [EMAIL PROTECTED] wrote:
On Tue, Nov 18, 2008 at 6:19 PM, Allen Tom [EMAIL PROTECTED] wrote:
Dirk Balfanz wrote:
Oh I see. Ok. I'l make a new revision
On Wed, Nov 19, 2008 at 10:14 AM, Breno de Medeiros [EMAIL PROTECTED]wrote:
On Tue, Nov 18, 2008 at 10:32 PM, Dirk Balfanz [EMAIL PROTECTED] wrote:
On Tue, Nov 18, 2008 at 10:04 PM, Breno de Medeiros [EMAIL PROTECTED]
wrote:
On Tue, Nov 18, 2008 at 10:00 PM, Dirk Balfanz [EMAIL
to just show an error page to the user
explaining what happened.
Dirk.
Allen
Dirk Balfanz wrote:
I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0
spec, with a new error_code value indicating that the either the CK or the
realm was invalid. There may actually
be changed to are in the phrase The following security
principles is reflected in this design
Done. Thanks for spotting these!
Dirk.
Otherwise, the spec is looking pretty good!
Allen
Dirk Balfanz wrote:
Ok, new version is up. I took out the sentence that recommended to send a
cancel. I
in the
ProblemReporting extension.
http://oauth.pbwiki.com/ProblemReporting
Allen
Dirk Balfanz wrote:
On Wed, Nov 19, 2008 at 2:31 PM, Allen Tom [EMAIL PROTECTED] wrote:
Since the new hybrid draft spec doesn't affect the OpenID association
method, this is moot.
However, the spec should
The following security
principles is reflected in this design
Otherwise, the spec is looking pretty good!
Allen
Dirk Balfanz wrote:
Ok, new version is up. I took out the sentence that recommended to send a
cancel. I also added a section on discovery (just copied whatever the AX
extension
On Mon, Nov 24, 2008 at 10:06 PM, Martin Atkins [EMAIL PROTECTED]wrote:
Dirk Balfanz wrote:
I'm not sure I understand what the commotion is about :-)
OAuth discovery (when it is done), will answer the question: given the
URL of a resource, where do I go to get access tokens
:
Dirk Balfanz wrote:
We're defining an OpenID extension. Consumer will want to know whether or
not a given endpoint speaks that extension. That's all it's doing - just
like AX or PAPE have a section on discoverability. It also gives consumers a
way to look for the combined OpenID/OAuth endpoint
is getting pretty close.
Thanks again, Allen - this is really helpful!
Dirk.
thanks
Allen
Dirk Balfanz wrote:
Otherwise, the spec is looking pretty good!
Great! We're officially calling it Draft 1 now :-) (the previous version
was Draft 0
On Tue, Nov 25, 2008 at 10:20 PM, Manger, James H
[EMAIL PROTECTED] wrote:
The latest OpenID/OAuth hybrid draft REQUIRES the openid.oauth.consumer
parameter, which means an app must be pre-registered with a service before
it can use the protocol.
Well, technically speaking, it requires the
On Sun, Nov 30, 2008 at 3:07 PM, Manger, James H
james.h.man...@team.telstra.com wrote:
here is a non-security reason [for openid.oauth.consumer in the
response]:
Imagine the Consumer controlling more than
one consumer key, and also imagine that the consumer is implemented as a
server
Wait - isn't Luke saying that Yahoo! is currently supporting this just fine?
What are you fixing?
Dirk.
On Tue, Mar 24, 2009 at 2:16 PM, Allen Tom a...@yahoo-inc.com wrote:
Hi Luke,
I have to confess that I was not aware of technique of passing parameters
after the fragment to take
On Thu, Mar 26, 2009 at 9:46 PM, Luke Shepard lshep...@facebook.com wrote:
This thread has been really useful – thanks for the responses everyone. I
have a few inline responses to a few different emails, bear with me while I
try to unify the thread.
From Breno:
The very legitimate
I don't see why a realm shouldn't be able to delegate to a return_to URL the
same way that a user id can delegate to an OP endpoint. This includes
delegating from http to https, or even to a different domain altogether.
Over on the XRI TC we've been talking about how to do this securely, e.g.,
by
Hi guys,
Google would like to launch a feature in which we're allowing our Google
Apps hosted domains to become OpenID providers. The authentication part of
it is pretty simple - Google is already logging in users to their apps, so
we can also host an OP endpoint for those domains and send
[+gene...@openid.net for a broader audience]
On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz balf...@google.com wrote:
Hi guys,
Google would like to launch a feature in which we're allowing our Google
Apps hosted domains to become OpenID providers. The authentication part of
it is pretty simple
are
doing as having a registry for experimental URIs would be good as well.
Thanks,
George
Dirk Balfanz wrote:
[+gene...@openid.net mailto:gene...@openid.net for a broader
audience]
On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz balf...@google.com
mailto:balf...@google.com wrote
27 matches
Mail list logo
