On 8/31/07, James Henstridge <[EMAIL PROTECTED]> wrote:
>
>
> You still want the user involved in the granting of an authentication
> token though, right? Trying to replace the "UA" in the authentication
> workflow is quite a big change, and limits what the OP can do.
Yes, granting the secret mu
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
I think I see where there might be confusion. When the initial request
occurs, we're actually doing a re-authentication with the client site. So
we're sending a check_id request with the return_to pointing to the client
site. Because we have some extra arguments (including the URL of the
destin
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
I believe I'm sticking to the same principles in my spec. We are doing the
very same thing when we coll
Ahhh, I see what you're going for. It's a very interesting idea.
On 8/30/07, James Henstridge <[EMAIL PROTECTED]> wrote:
>
> 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. Ca
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 creat
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?
I was really trying to keep everything dumb and simple. The concept I was
going for was "piggy-back on Ope
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.
Chris,
I want to start off by saying how horribly inappropriate it is to use the
OpenID specifications mailing list to peddle an authentication standard that
has absolutely nothing to do with OpenID.
I find it interesting that so many of the OAuth community have taken time
out of their busy sched
Hi John,
Looks like there's some consensus around OAuth... ;)
I helped to get OAuth off the ground to solve the very problem that
you're looking to solve -- in our case, enabling Ma.gnolia OpenID
users to use Dashboard Widgets and Twitter API users to authenticate
their apps, eventually using Ope
John,
Have a look at OAuth (http://groups.google.com/group/oauth). I think it's
currently a private google group, but it seems like you've given a lot of
thought to this type of thing, so I'm sure the group owners would welcome
your input. There's a lot of activity going on over there.
David
O
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 instance,
Basecamp provides an API that allows other
12 matches
Mail list logo
