On 10-Jul-07, at 10:52 AM, Johnny Bufu wrote:
>
> On 10-Jul-07, at 8:43 AM, James Henstridge wrote:
>
>> On 10/07/07, Dick Hardt <[EMAIL PROTECTED]> wrote:
>>> > Given that there doesn't seem to be any way to recover from this
>>> > situation, it seems like private associations are the only sane
On 10-Jul-07, at 8:43 AM, James Henstridge wrote:
> On 10/07/07, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> > Given that there doesn't seem to be any way to recover from this
>> > situation, it seems like private associations are the only sane
>> option
>> > for unsolicited responses.
>>
>> An up
On 10-Jul-07, at 8:43 AM, James Henstridge wrote:
> On 10/07/07, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> > Given that there doesn't seem to be any way to recover from this
>> > situation, it seems like private associations are the only sane
>> option
>> > for unsolicited responses.
>>
>> An up
On 10/07/07, Dick Hardt <[EMAIL PROTECTED]> wrote:
> > Given that there doesn't seem to be any way to recover from this
> > situation, it seems like private associations are the only sane option
> > for unsolicited responses.
>
> An update message would require direct verification and not use an
>
On 10-Jul-07, at 8:29 AM, James Henstridge wrote:
> [replying to myself]
>
> On 10/07/07, James Henstridge <[EMAIL PROTECTED]> wrote:
>> The only real constraint the authentication spec places on the RP is
>> that it maintain the association for the duration of an OpenID
>> authentication request
[replying to myself]
On 10/07/07, James Henstridge <[EMAIL PROTECTED]> wrote:
> The only real constraint the authentication spec places on the RP is
> that it maintain the association for the duration of an OpenID
> authentication request.
>
> With unsolicited response though, there is no prior re
On 10-Jul-07, at 1:47 AM, James Henstridge wrote:
>
I don't think it's implied anywhere (or a good design) to keep
state
between the original request and subsequent updates. So the RP
cannot
infer the 'removed' statement just because an update did not
contain
>
On 10-Jul-07, at 1:47 AM, James Henstridge wrote:
> On 10/07/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>>
>> On 6-Jul-07, at 3:54 AM, James Henstridge wrote:
>>> Would that be appropriate to include in the spec or some best
>>> practices document?
>>
>> I see this as a pure OpenID (core) is
On 10/07/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>
> On 6-Jul-07, at 3:54 AM, James Henstridge wrote:
> >> Not entirely; the OP MUST NOT honor check_authentication requests for
> >> shared associations (this would allow a type of attack).
> >
> > Okay. In that case it sounds like it would be be
On 6-Jul-07, at 3:54 AM, James Henstridge wrote:
>> Not entirely; the OP MUST NOT honor check_authentication requests for
>> shared associations (this would allow a type of attack).
>
> Okay. In that case it sounds like it would be best practice to
> generate a private association handle for each
On 06/07/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>
> On 6-Jul-07, at 12:37 AM, James Henstridge wrote:
> > My question about the transaction ID in the update URL still stands:
> > won't a positive assertion response include openid.identifier and
> > openid.claimed_id, which should be enough for
On 6-Jul-07, at 12:37 AM, James Henstridge wrote:
> My question about the transaction ID in the update URL still stands:
> won't a positive assertion response include openid.identifier and
> openid.claimed_id, which should be enough for the RP to match up the
> response? Or do you expect the OP t
On 06/07/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> Hi James!
>
> On 4-Jul-07, at 9:05 PM, James Henstridge wrote:
> > 1. I noticed a few typos in the examples. In section 5.1, it gives an
> > example of a fetch_request request reading:
> >
> > openid.ns.ax=http://openid.net/srv/ax/1.0
> >
Hi James!
On 4-Jul-07, at 9:05 PM, James Henstridge wrote:
> 1. I noticed a few typos in the examples. In section 5.1, it gives an
> example of a fetch_request request reading:
>
> openid.ns.ax=http://openid.net/srv/ax/1.0
> openid.ns.ax=fetch_request
> ...
This would be a copy / pas
Hi,
I was looking at the attribute exchange protocol spec (draft 5), and
had a few questions about it:
1. I noticed a few typos in the examples. In section 5.1, it gives an
example of a fetch_request request reading:
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ns.ax=fetch_request
15 matches
Mail list logo
