On 3/26/07, Johnny Bufu [EMAIL PROTECTED] wrote:
Since draft_4 [1] we've done some implementation and testing (as well
as listened to community's suggestions on related issues), and have
incorporated some changes into a pre-draft-5. Before publishing it I
would like to see your comments about
Johnny Bufu wrote:
This is basically a push approach, as opposed to the pull approach
you were suggesting.
I'm new to OpenID, and no engineer, but I have to say that I have a bad
feeling about this 'push' approach. It inverts the relationship between
client and server and seems entirely
On 3-Apr-07, at 3:32 AM, Josh Hoyt wrote:
If I understand correctly, the response to a request for an attribute
with count.x=1 is different from the response for a request with no
count specified, even though the meaning is the same.
(namespacing left off for clarity)
Request:
Good questions to tease out the logic behind the architecture Anders,
responses to each of your points below ...
On 3-Apr-07, at 6:18 AM, Anders Feder wrote:
Johnny Bufu wrote:
This is basically a push approach, as opposed to the pull approach
you were suggesting.
I'm new to OpenID, and
On 3-Apr-07, at 8:24 AM, Dick Hardt wrote:
On 2-Apr-07, at 11:50 AM, Chris Drake wrote:
User Centric implies that sites don't store anything about me, and
that whenever they need to know stuff (eg: my email), they instead
ask
my OpenID server, which returns them the answer (unless I've
On 3-Apr-07, at 9:18 AM, Anders Feder wrote:
* The RP can't know the status of the information it is working with -
it just have to assume that the attributes it has in store are up-
to-date.
The RP can send an update_url to the OP when it fetches the
attributes, so it will get new values
As an end-user to user-centric approaches, I have noticed an interesting
pattern. Microsoft does a wonderful job of selling Cardspace as a solution to
others who develop in Microsoft languages. Likewise, there are tons of vendors
that can offer solutions for large enterprises to purchase but no
Rowan,
Thanks for your response. Again, I have no formal education, so don't
bother if my comments are worthless. I just want to specify the concerns
I do have, based on my own experience, in case they are of any use to
the process.
Rowan Kerr skrev:
The RP can send an update_url to the OP
People might be, though nothing real formal that I personally know of.
You volunteering? :P
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of McGovern, James F (HTSC, IT)
Sent: Monday, April 02, 2007 8:15 AM
To: specs@openid.net
Subject: Promoting
More likely that the people promoting OpenID to large organizations are
vendors and don't particularly want to tell their competitors what they are
doing.
Now, imagine if there were like-minded vendors getting together to form some
sort of marketing organization to promote OpenID to a variety of
Gabe, I think you nailed it. The problem I run across is that my interest in
using OpenID is all about getting a federation of sorts up and working within
my insurance vertical which contains 250 distinct competitors. Getting emails
offlist privately with vendors marketing uniquely to me is not
Imagine the waves through the technology community when end-customers stand up
and preach how to code to vendors. Sadly, I am only outlining the problem space
in hopes that others could step up and run with it. I think it would be
appropriate for me to participate in panel discussions at
Anders,
On 4/3/07, Anders Feder [EMAIL PROTECTED] wrote:
Rowan Kerr skrev:
The RP can send an update_url to the OP when it fetches the
attributes, so it will get new values when the user changes them at
the OP.
But the RP can't know if the update_url is honored, i.e. if it will
ever
Dick Hardt wrote:
There are two common client server design patterns. Request / Response
and Publish / Subscribe.
I see - I was not aware that the latter model was so well-understood in
the client/server paradigm.
The RP has what ever the user last gave the RP. If the user is
involved in
On Apr 3, 2007, at 9:14 PM, Wayne Pierce wrote:
One could say that OpenID should not be relied on to exchange
sensitive
information like bank account numbers, but 1) I think its a shame to
limit a technology with such great potential, and 2) chances are that
OpenID will be relied upon
Wayne Pierce wrote:
When I update my information at a new OP how about some way to tell
the RP it is the most authoritative. Not sure if this should be taken
care of at the application or protocol level, I'd like to see it in
the protocol though. The big concern I see with this is that
On 3-Apr-07, at 3:05 PM, Anders Feder wrote:
Dick Hardt wrote:
There are two common client server design patterns. Request /
Response
and Publish / Subscribe.
I see - I was not aware that the latter model was so well-
understood in
the client/server paradigm.
The RP has what ever
On Apr 3, 2007, at 16:20, Dick Hardt wrote:
The FOAF camp was rolling along with the Pull model until they
realized the issues around access control of the data.
...
Push is actually much simpler then Pull for any kind of sensitive
data, which is most of the useful attribute data.
I
Ping demoed OpenID technology at RSA.
I hear Novell and IBM are looking at supporting OpenID.
Microsoft has said they will in future products.
Oracle and CA are following OpenID.
So, yes. :-)
On 2-Apr-07, at 8:21 AM, McGovern, James F ((HTSC, IT)) wrote:
Unlike blog sites and Internet
I can see an OP thinking that AX is a big step, but have a hard time
seeing it to be that big for an RP (once there are libraries that
support AX) ... and it is really not that much more to do AX over
SREG for an RP.
Where you thinking OP or RP David?
-- Dick
On 3-Apr-07, at 12:17 PM,
20 matches
Mail list logo
