On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com wrote:
One crude way to do it would be to have the caller specify that they want
the return_to args simply appended instead of integrated into the URL-
perhaps an argument like openid.append_return_to_params=true. But that
On Thu, Mar 26, 2009 at 1:49 AM, Martin Atkins m...@degeneration.co.uk wrote:
James Henstridge wrote:
On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com
wrote:
One crude way to do it would be to have the caller specify that they want
the return_to args simply appended
2009/1/7 David Fuelling sappe...@gmail.com:
All,
Wondering if anybody, especially the original OIDF Board and any
contributor's to the OpenID Auth 2.0 spec could comment on this question for
me.
Is OpenID Discovery, as seen in section 7.3 of the Auth spec, optional?
More specifically, is
On Thu, Aug 21, 2008 at 12:49 AM, Scott Battaglia
[EMAIL PROTECTED] wrote:
Thanks for the reply...some comments in-line!
On Fri, Aug 15, 2008 at 6:26 AM, James Henstridge [EMAIL PROTECTED]
wrote:
2008/8/15 Scott Battaglia [EMAIL PROTECTED]:
snip /
1. Do you guys support accessing
2008/8/15 Scott Battaglia [EMAIL PROTECTED]:
Hi everyone,
I'm the lead developer on the JASIG Central Authentication Service, one of
the SSO servers that a number of higher education institutions use.
Traditionally, CAS has used its own de-facto standard protocol (CAS1 and
CAS2) which are
On Wed, Aug 13, 2008 at 3:56 AM, Martin Atkins [EMAIL PROTECTED] wrote:
The Net::OpenID::Consumer perl library as it currently stands will not
support PAPE in 1.1-mode messages since the openid.ns.alias mechanism
is only used in 2.0 mode. I'd like to change this to use the 2.0 scheme
in 1.1
On Wed, Jul 16, 2008 at 12:38 PM, Anders Feder [EMAIL PROTECTED] wrote:
tir, 15 07 2008 kl. 21:28 -0700, skrev John Panzer:
And of course any number of extensions could be created to obtain an
access token via an alternate path, after which normal OAuth can be
used.
Sure, but isn't this
On 10/04/2008, Vinay Gupta [EMAIL PROTECTED] wrote:
I think that kind of misses the point. The *namespace* that google manages
is now open for business as an OpenID provider. It's an unanticipated
side-effect of the APIs.
I think it's kind of a big deal, actually, in terms of how OpenID is
On 10/04/2008, Brad Fitzpatrick [EMAIL PROTECTED] wrote:
On Thu, Apr 10, 2008 at 12:40 AM, James Henstridge [EMAIL PROTECTED]
wrote:
On 10/04/2008, Vinay Gupta [EMAIL PROTECTED] wrote:
I think that kind of misses the point. The *namespace* that google
manages
is now open for business
On 02/04/2008, Paul E. Jones [EMAIL PROTECTED] wrote:
A solution that matches closer with what the user expects would be to
map [EMAIL PROTECTED] to a claimed ID of mailto:[EMAIL PROTECTED].
The average user is not going to know what mailto:; is.
The mailto: transition would be something
On 02/04/2008, Paul E. Jones [EMAIL PROTECTED] wrote:
Folks,
I've seen discussion here and there on the use of the e-mail address as the
OpenID identifier. Perhaps this one says it best:
http://www.majordojo.com/2007/02/what-openid-needs.php
I share many of same opinions. If OpenID is
On 02/04/2008, Paul E. Jones [EMAIL PROTECTED] wrote:
Brad,
Your point about DNS limitations is valid. Then again, anybody who will be
offering the open identity server is likely going to have control over their
DNS. Still, I'm not opposed to alternatives.
But, since you brought up the
On 12/03/2008, techtonik [EMAIL PROTECTED] wrote:
So, if I understand correctly there is no way for consumer to detect which
version - 1.0 or 1.1 is used in HTML delegation case, because delegation
tags are the same, i.e.
link rel=openid.server
On 21/02/2008, Enis Soztutar [EMAIL PROTECTED] wrote:
Hi,
As far as I understand, the distinction between sreg.required and
sreg.optional is entirely in the responsibility of the consumer and
there is not reason for the protocol to include this arbitrary division.
An OP implementation
On 04/02/2008, Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED] wrote:
James Henstridge wrote:
Of course, the OP is restricted to returning identities that it is
authoritative for. This is what allows any yahoo user to enter
yahoo.com as their OpenID identifier while still letting RPs tell
On 02/02/2008, Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED] wrote:
Yes, I also wonder why the IDP can't just return the ID. As of now I think
it's
two steps for this, with the RP explicit requesting it? Or am I wrong with
that?
When used in directed identity mode, the OP can pick the
On 02/02/2008, McGovern, James F (HTSC, IT)
[EMAIL PROTECTED] wrote:
Figured I would ask if anyone is interested in brainstorming the next
version of OpenID and how it can be used in Enterprise B2B settings and not
solely focusing on consumerish interactions. Some things that I would like
to
On 02/02/2008, Kevin Turner [EMAIL PROTECTED] wrote:
On Sat, 2008-02-02 at 08:51 +1100, James Henstridge wrote:
5. A way for OpenID relying parties to filter out Ops. In a business
scenario, if I run the Sun employee store, I may only want the Sun OP to
talk with me.
This is already
On 29/10/2007, John Ehn [EMAIL PROTECTED] wrote:
I've been reviewing Draft 12, and noticed this section, which I think will
cause problems for some systems.
9.2.1. Using the Realm for Return URL Verification
OpenID providers SHOULD verify that the return_to URL specified in the
request is
On 18/10/2007, Johnny Bufu [EMAIL PROTECTED] wrote:
Hi James,
On 17-Oct-07, at 2:42 AM, James Henstridge wrote:
I have a few more questions about the update_url feature of OpenID
attribute exchange that I feel could do with answers in the
specification.
For the questions, imagine
On 17/10/2007, Manger, James H [EMAIL PROTECTED] wrote:
Other solutions:
OPs can offer different authentication mechanisms based on the
openid.return_to or openid.realm parameter in an authentication request.
However, the user has less flexibility when they have to relying on OPs.
If the
I have a few more questions about the update_url feature of OpenID
attribute exchange that I feel could do with answers in the
specification.
For the questions, imagine an OpenID RP with the following properties:
1. The RP provides a unified login/signup workflow, so that if a user
signs in with
On 31/08/2007, John Ehn [EMAIL PROTECTED] wrote:
Well, I've slept on it. I think we have a difference in philosophy.
The other Extesions - AX, Simple Registration, etc. - follow the same data
flow methodology:
RP - UA - OP
RP - UA - OP
With my proposed workflow, it'd be going through the
On 26/08/07, John Ehn [EMAIL PROTECTED] wrote:
I have created a draft of a new specification that I think will help to fill
a gap in OpenID functionality.
What appears to be a newer productivity feature of many websites is the
ability to import and utilize information from other sites. For
On 30/08/2007, John Ehn [EMAIL PROTECTED] wrote:
James,
Sorry, but I'm having problems following the flow. It seems like an
interesting idea, though. Can you provide with a little more information on
how these components would interact?
Okay. The basic idea was that instead of creating a
[replying to myself]
On 10/07/07, James Henstridge [EMAIL PROTECTED] wrote:
The only real constraint the authentication spec places on the RP is
that it maintain the association for the duration of an OpenID
authentication request.
With unsolicited response though, there is no prior request
On 10/07/07, Dick Hardt [EMAIL PROTECTED] wrote:
Given that there doesn't seem to be any way to recover from this
situation, it seems like private associations are the only sane option
for unsolicited responses.
An update message would require direct verification and not use an
On 06/07/07, Johnny Bufu [EMAIL PROTECTED] wrote:
On 6-Jul-07, at 12:37 AM, James Henstridge wrote:
My question about the transaction ID in the update URL still stands:
won't a positive assertion response include openid.identifier and
openid.claimed_id, which should be enough for the RP
Hi,
I was looking at the attribute exchange protocol spec (draft 5), and
had a few questions about it:
1. I noticed a few typos in the examples. In section 5.1, it gives an
example of a fetch_request request reading:
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ns.ax=fetch_request
29 matches
Mail list logo
