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 m
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 secu
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 langua
On Apr 5, 2007, at 10:40 AM, Douglas Otis wrote:
> Although the world demands GUI, terminal interfaces already offer a
> powerful set of tools for doing exactly what is needed. Public key
> cryptography reduces the overhead and security concerns substantially.
> This may also provide an alternat
[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 legit
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
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, et
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 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
>
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,
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, the
> RP has been preparing a payment for a job you have
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 think
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
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 a
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 rel
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
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
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
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
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 (un
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,
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 since
> revoked permission or whatever). Agai
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 co
Chris,
On 2-Apr-07, at 11:50 AM, Chris Drake wrote:
> I've also noticed a lot of discussion about attributes, which begs the
> question about how to handle things that change (eg: If I've given out
> my email address to a dozen web sites, and then I change it, how does
> my OpenID server propagat
24 matches
Mail list logo
