c: 'OpenID specs list'
Subject: Re: Specifying identifier recycling
I think you are making an invalid analogy. What prevents you from
setting up a "private key reset" function the same way you set up a
"password reset" function, using an alternate credential?
verification, I think :-)
>
> Having said that, I do agree that we should be completing 2.0 cycle
> quickly and making it SIMPLE!
>
> Nat
>
>
>> -Original Message-
>> From: Johannes Ernst [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, June 05, 2007 1:45 PM
&
-Original Message-
> From: Johannes Ernst [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 05, 2007 1:45 PM
> To: =nat
> Cc: 'OpenID specs list'
> Subject: Re: Specifying identifier recycling
>
> I would postulate that if you want to be able to pro
e "WordPress" User Problem (WAS: RE: Specifying
identifier recycling)
On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote:
> The relying parties SHOULD make the fragment available to software
> agents, at least, so that it's possible to compare identifiers across
> sites. If the fragment
On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote:
> The relying parties SHOULD make the fragment available to software
> agents, at least, so that it's possible to compare identifiers across
> sites. If the fragment is never available, then there is confusion
> about which user of an identifier is respons
specs list
Subject: Re: The "WordPress" User Problem (WAS: RE: Specifying
identifier recycling)
On 6/5/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> > The fragment is not secret. It is not "protecting" your OpenID. You
> > should be able to get the fragment fro
On 6/5/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> > The fragment is not secret. It is not "protecting" your OpenID. You
> > should be able to get the fragment from any relying party that you
> > visited.
>
> I believe David's point is that you cannot retrieve the fragment from
> the RP if you hav
On 5-Jun-07, at 11:12 AM, Josh Hoyt wrote:
> On 6/5/07, Recordon, David <[EMAIL PROTECTED]> wrote:
>> Imagine if I install WordPress (or insert other app here) on
>> https://davidrecordon.com and check the "Use fragments to protect my
>> OpenID" box. A few months later I decide to remove WordPre
On 6/5/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Imagine if I install WordPress (or insert other app here) on
> https://davidrecordon.com and check the "Use fragments to protect my
> OpenID" box. A few months later I decide to remove WordPress, or an
> upgrade blows away my OpenID extension
On 5-Jun-07, at 8:00 AM, Recordon, David wrote:
> I think the largest concern I have with fragments, or really any
> pair-wise shared secret which can't be renegotiated, is that while it
> solves issues for the large service providers it actually inhibits
> OpenID within the grassroots community.
n issues.
I think my preference is #3, though I'm sure it has its own issues.
--David
-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 03, 2007 6:35 PM
To: Recordon, David
Cc: Johannes Ernst; OpenID specs list
Subject: Re: Specifying identifier recyc
ty secret :-p
>
> =nat
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt
>> Sent: Sunday, June 03, 2007 8:24 PM
>> To: Johannes Ernst
>> Cc: OpenID specs list
>> Subject: Re: Specifying iden
On 4-Jun-07, at 7:51 AM, Granqvist, Hans wrote:
>> So I ask again - does anyone see any issues with the
>> fragments being used like this:
>>
>> http://openid.net/pipermail/specs/2007-May/001767.html
>>
>
> Seems reasonable in essence. But it adds complexity and
> removes some immediacy of
> So I ask again - does anyone see any issues with the
> fragments being used like this:
>
> http://openid.net/pipermail/specs/2007-May/001767.html
>
Seems reasonable in essence. But it adds complexity and
removes some immediacy of URL identifiers-as-is.
Do fragments need special handl
Hi.
My comments in-line below:
On Saturday, June 02, 2007 5:40 AM, Johannes Ernst wrote:
>
> On May 31, 2007, at 18:41, Nat Sakimura wrote:
>
> > Public key idea is somewhat attractive to me, but there are some
> > issues that comes up in my mind as well.
>
> Bring them on ;-)
>
> > 1) St
PM
> To: Johannes Ernst
> Cc: OpenID specs list
> Subject: Re: Specifying identifier recycling
>
> There is a huge difference between the OP/RP shared secret
> and using a shared secret as an identifier.
>
> The secret between the OP and RP has a mechanism for it to be
&
>> Johnny Bufu wrote:
>>
>> We did look at this (with Drummond) in December. The bottom line is
>> that it can't be done easily - a mechanism similar to XRI's canonical
>> ID verification would have to be employed, to confirm that the i-
>> number actually 'belongs' to the URL on which disco
On 3-Jun-07, at 1:46 AM, Recordon, David wrote:
> I thought at IIW we agreed that if we could come to quick consensus
> on a
> way to resolve the problem it would be a part of 2.0, otherwise it
> would
> not...
Agreed, nobody wants to delay 2.0 indefinitely if we can't agree on
how to solv
On 3-Jun-07, at 10:46 AM, Recordon, David wrote:
> I thought at IIW we agreed that if we could come to quick consensus
> on a
> way to resolve the problem it would be a part of 2.0, otherwise it
> would
> not...
That is what we agreed to in Josh's meeting. Then we had a meeting
the next da
>>
>> =Drummond
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf
>> Of Johannes Ernst
>> Sent: Wednesday, May 30, 2007 9:54 PM
>> To: OpenID specs list
>> Subject: Re: Specifying identifier
A little late to the conversation, but some comments inserted as I
did not see them all in any other aspect of this thread ...
On 30-May-07, at 10:28 PM, Josh Hoyt wrote:
> Hello,
>
> I started writing up the use of fragment identifiers for URL-recycling
> for the OpenID 2.0 authentication spec
On 3-Jun-07, at 2:14 AM, Recordon, David wrote:
>> Overall, I'm not sure we are ready in this community to pick one
>> alternative over another as "the standards". I have my views,
>> (many) others have (many) others -- and I don't think that any
>> of this has to be in an Authentication 1.x (x>1
PM
To: Recordon, David
Cc: Johannes Ernst; OpenID specs list
Subject: Re: Specifying identifier recycling
On 2-Jun-07, at 5:14 PM, Recordon, David wrote:
> I'd like to see this written as an
> extension so that if the first approach doesn't work, the Auth spec
> itself doesn
I wasn't in that session (as far as I recall ;-)) so I don't know
either what was agreed on, or who agreed, or for what reasons ... the
thread so far does not look like it was a very stable agreement ;-)
On Jun 2, 2007, at 22:11, Johnny Bufu wrote:
>
> On 2-Jun-07, at 5:14 PM, Recordon, Dav
On 2-Jun-07, at 5:14 PM, Recordon, David wrote:
> I'd like to see this written as an
> extension so that if the first approach doesn't work, the Auth spec
> itself doesn't have to be "reverted. Rather we can finish 2.0 and try
> implementing different approaches before deciding on the final way t
s).
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Johannes Ernst
Sent: Wednesday, May 30, 2007 10:30 PM
To: OpenID specs list
Subject: Re: Specifying identifier recycling
If we cannot assume that nobody manages to obtain a secret they
should no
Would have to agree with what Johannes has said. :)
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Johannes Ernst
Sent: Wednesday, May 30, 2007 1:53 PM
To: Josh Hoyt
Cc: OpenID specs list
Subject: Re: Specifying identifier recycling
On May 30
Nat Sakimura schrieb:
> 1) Storing many users' private key on the server in decryptable format is
> not very safe.
>
> In your proposal, it looks like that OP is going to hold the private key for
> each user in decryptable format. Considering that most large scale privacy
> leakage happens at the
To: Nat Sakimura
Cc: 'OpenID specs list'
Subject: Re: Specifying identifier recycling
On May 31, 2007, at 18:41, Nat Sakimura wrote:
> Public key idea is somewhat attractive to me, but there are some
> issues that
> comes up in my mind as well.
Bring them on ;-)
>
uirement for OpenID usage ...)
Personally I would feel we didn't think hard enough on this
particular problem if the solution to this problem required us to use
centralization of some kind.
>
> =nat
>
>
>
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED
Johnny Bufu wrote:
>
> We did look at this (with Drummond) in December. The bottom line is
> that it can't be done easily - a mechanism similar to XRI's canonical
> ID verification would have to be employed, to confirm that the i-
> number actually 'belongs' to the URL on which discovery was
D] On Behalf Of Johannes Ernst
> Sent: Thursday, May 31, 2007 2:30 PM
> To: OpenID specs list
> Subject: Re: Specifying identifier recycling
>
> If we cannot assume that nobody manages to obtain a secret they
> should not have gotten in the first place, then OpenID as it stand
eing
> revoked.
>
> =Drummond
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf
> Of Johannes Ernst
> Sent: Wednesday, May 30, 2007 9:54 PM
> To: OpenID specs list
> Subject: Re: Specifying identifier recycling
>
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Johannes Ernst
Sent: Wednesday, May 30, 2007 9:54 PM
To: OpenID specs list
Subject: Re: Specifying identifier recycling
On May 30, 2007, at 21:02, Johnny Bufu wrote:
> ...The bottom line is
> that it can't be done easily - a mechanism
>>> John Panzer wrote:
>>>
>>> Has there been a discussion about an extension to map to/from i-
>>> numbers
>>> via AX? If there were a generic attribute you could stuff an i-
>>> number
>>> or a hash of an internal ID in there to help solve the disambiguation
>>> problem. Alternatively it'd b
On May 30, 2007, at 21:02, Johnny Bufu wrote:
...The bottom line is
that it can't be done easily - a mechanism similar to XRI's canonical
ID verification would have to be employed, to confirm that the i-
number actually 'belongs' to the URL on which discovery was
initiated. (Otherwise anyone co
Josh,
On 30-May-07, at 1:28 PM, Josh Hoyt wrote:
> Providers can also provide a redirect from the general form of the
> identifier to the current version of the identifier so that users do
> not need to remember or type the uniquified version. This is pretty
> much equivalent to the fragment sche
On 30-May-07, at 1:28 PM, Josh Hoyt wrote:
> How should the discovery process work?
> How should fragments work with delegation (both as the claimed
> identifier and the provider-local identifier)?
Here's how I see the fragments approach working:
a) Discovery: strip the fragment from the user-s
On 30-May-07, at 6:21 PM, Martin Atkins wrote:
> John Panzer wrote:
>>
>> Has there been a discussion about an extension to map to/from i-
>> numbers
>> via AX? If there were a generic attribute you could stuff an i-
>> number
>> or a hash of an internal ID in there to help solve the disambigu
John Panzer wrote:
>
> Has there been a discussion about an extension to map to/from i-numbers
> via AX? If there were a generic attribute you could stuff an i-number
> or a hash of an internal ID in there to help solve the disambiguation
> problem. Alternatively it'd be nice to have a way to
At some point, the weak link will be humans trying to disambiguate
http://joe.example.org/ from http://joe.example.org/2 (or
http://joe.example.org/#2). I don't think there's a big difference
between the two in that context, and I don't think that OID2 needs to
solve this more deeply than allo
On May 30, 2007, at 13:28, Josh Hoyt wrote:
After thinking this over for a while, I'm no longer convinced that
using URI fragments as the uniquifying value is the right
approach.
I agree with you. Our reasons may differ slightly, but the result is
the same.
I have no problem in not solving
42 matches
Mail list logo