[I initially sent this to Chris directly, because he sent his message to
me directly. Then I noticed he'd also replied on the list. Hopefully
he'll see this before my private reply and we can avoid another
go-around of duplicate messages!]
Chris Drake wrote:
MA For some things it's
On Wed, 2007-04-04 at 20:02 +, Vinay Gupta wrote:
On Apr 4, 2007, at 7:43 PM, Douglas Otis wrote:
Hm. Well, I don't to suggest that we tear off fixing or expressing
the whole semantics of PKI, but I do think that some care should be
taken to make sure that it's clear what the security
One further thought on Kerberos: as far as I know, Kerberos is a
minimal implementation - nothing simpler than this actually works in
the real world, and the Kerberos operating environment is a bit
simpler than what is being discussed in some instances here, in terms
of managing the
Chris Drake wrote:
Hi Martin,
Yes - sorry - I accidentally hit reply instead of reply all. I
later did re-post to the list though. For the benefit of the list,
your reply is at the end here.
Re-reading my reply, I think my wording sounded pretty strong, and I
might not have made it
Chris Drake wrote:
Hi Martin,
You wrote
MA The age of the information needs to be taken into account here.
When the information (rightly) lives at the OP instead of the RP, none
of that age complexity exists.
It's *my* name. It's *my* credit card. If any RP wants this info, make
them
On Apr 4, 2007, at 12:45 AM, Martin Atkins wrote:
Anders Feder wrote:
Imagine an RP requesting your bank account number X from your OP.
Time
goes by, and your OP goes out of business. Later, you switch banks
and
your account number X is assigned to someone else. In the
meantime,
On Apr 4, 2007, at 6:13 PM, Douglas Otis wrote:
This may seem to be off topic, but I really don't see reluctance in
using public key cryptography. DKIM would be one such example.
Nearly every gateway, and access point can utilize this means of
authentication. Think of this as yet another
On Apr 4, 2007, at 11:44 AM, Vinay Gupta wrote:
On Apr 4, 2007, at 6:13 PM, Douglas Otis wrote:
There could be keys used to authorize some other automated
service, or to act as a replacement for OpenID once the key has
been established. One might be defined for email, IM, VoIP, etc.
On Apr 4, 2007, at 7:43 PM, Douglas Otis wrote:
Related services that can be enabled by using OpenID as a key
distribution scheme. Keys would need to relate to services handled
by the consumer or RP. A sub-attribute could help facilitate
correct placement of the keys and to allow
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
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
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
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
20 matches
Mail list logo
