On 4-Apr-07, at 8:59 PM, Chris Drake wrote:
> Thursday, April 5, 2007, 5:43:02 AM, you wrote:
>
> [snip]
>
> DO> How these keys are handled internally could be left to the
> DO> consumer or RP.
>
> [snip]
>
> This sounds like another *strong* use-case for updating the OpenID
> protocol to allow t
Thursday, April 5, 2007, 5:43:02 AM, you wrote:
[snip]
DO> How these keys are handled internally could be left to the
DO> consumer or RP.
[snip]
This sounds like another *strong* use-case for updating the OpenID
protocol to allow transactions to take place when the user is not
present.
I am no
This was, of course, the original LID design, and you are presenting
the rationale for it.
See http://lid.netmesh.org/
On Apr 4, 2007, at 20:59, Chris Drake wrote:
> Thursday, April 5, 2007, 5:43:02 AM, you wrote:
>
> [snip]
>
> DO> How these keys are handled internally could be left to the
>
Thursday, April 5, 2007, 3:50:49 AM, Martin wrote:
MA> 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.
>>
>> I
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 come to me (my OP) and get
Hi All,
Since it's a lot easier to just put a server-to-server mechanism in
place, than it is to argue about what it should be used for - can we
perhaps instead attempt to agree that server-to-server is going to be
something potentially useful in at least some cases, and go ahead and
specify it?
