For posterity, here's how I'd summarize this thread about using public keys
as persistent identifiers:
1) Yes, a public key could be used as an identifier, and could serve as a
persistent identifier if it was not reassignable.
2) The issue of it becoming invalid as a credential if the private key
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? You allow
for this for non-public-key credentials but not for others ...
But I don't want to perpetu
Hi.
Ok. Now I see the heart of the topic :-)
Fundamental difference is that you postulate that one cannot lose one's
credential including all the information that bears onto establish one's
identity while I do not postulate so.
For example, one can loose one's password and reset it.
You can
Yes, I think this would be worthwhile to write-up.
--David
-Original Message-
From: =drummond.reed [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 05, 2007 4:55 PM
To: Recordon, David; 'Johnny Bufu'
Cc: 'OpenID specs list'
Subject: RE: The "WordPress" User Problem (WAS: RE: Specifying
ide
David, just want to reinforce that the CanonicalID element in XRDS has
always been defined as containing anyURI, so it's been there to support
mapping of any reassignable identifier to any persistent identifier (or,
technically, any canonical identifier, even if not persistent, though
persistence i
At that point I'd be concerned as to solving the "big OP issue" while
not solving the "lost domain issue" when some of the proposals could
possible solve both. This largely focuses around using an XRI-style
canonical id, whether that be an i-number or just another "ugly" URL
which points back at t
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
I thought the fragment was to be secret so that for the case of using a
personal domain you don't have to own joshhoyt.com forever. Rather as
long as your fragments are secret, someone else can buy joshhoyt.com and
not be you. If this is no longer a requirement then it certainly
changes the game,
I wasn't at IIW, so please bear with me.
In reference to the wiki at
http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling, can somebody
clarify what some of the terminology means? Specific questions are below.
1.) For URL+Fragment, what is the distinction between "private" and
"public
>> =drummond.reed wrote:
>>
>> As Martin has pointed out, the purpose of the CanonicalID element in XRDS
is
>> to support reassignable-to-persistent identifier mapping. Although this
is a
>> native function of XRI resolution (because XRI architecture was
explicitly
>> designed to address the reas
On 6/5/07, Drummond Reed <[EMAIL PROTECTED]> wrote:
> I supposed this doesn't apply to large sites, where all identifiers are
> managed "in trust" for users and they can enforce non-access to previous
> fragments. But for personal URLs it doesn't appear to work at all. Am I
> missing anything?
Ena
>Josh Hoyt 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. You might choose to use a fragment if you have acquired a
>recycled identifier, but you can choose the fragment. It protects
>*nothi
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 5-Jun-07, at 8:53 AM, Granqvist, Hans wrote:
> But it seems superflous: Since you cannot depend on args to
> be ordered[1], you'll still need to iterate and match prefix
> to values.
Martin's proposal seems like a minor improvement to me - iterating
thorough openid.ns.* or splitting the valu
On 5-Jun-07, at 8:53 AM, Granqvist, Hans wrote:
>> But it seems superflous: Since you cannot depend on args to
>> be ordered[1], you'll still need to iterate and match prefix
>> to values.
>Martin's proposal seems like a minor improvement to me - iterating
>thorough openid.ns.* or splitting the
Hi Drummond,
On 5-Jun-07, at 9:44 AM, =drummond.reed wrote:
> I see no reason we can't add the rules for
> reassignable-URL-to-persistent-URL mapping as well, since it's
> simply a
> matter of the RP confirming that the persistent identifier is also
> authoritative for the XRDS.
>
> If we appro
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
Johnny Bufu wrote:
> On 5-Jun-07, at 8:53 AM, Granqvist, Hans wrote:
>
>> But it seems superflous: Since you cannot depend on args to
>> be ordered[1], you'll still need to iterate and match prefix
>> to values.
> Martin's proposal seems like a minor improvement to me - iterating
> thorough open
=drummond.reed wrote:
>
> As Martin has pointed out, the purpose of the CanonicalID element in XRDS is
> to support reassignable-to-persistent identifier mapping. Although this is a
> native function of XRI resolution (because XRI architecture was explicitly
> designed to address the reassignable-
On 6/5/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Since it seems no one has replied yet, I'd agree that this would make
> implementations easier. Iterating via a regular expression seems ugly
> and hard to do (well except in Perl). :-\
-1. It's one more thing to get wrong. There would then
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.
>David Recordon wrote:
>
>
>I don't want to say that I have the answers here, since I don't think I
>do. I do however see the following possible solutions:
>
>1) The core specification only talks about fragments in relation to
>Relying Parties, to the extent that they should be stripped from dis
But it seems superflous: Since you cannot depend on args to
be ordered[1], you'll still need to iterate and match prefix
to values.
Also, any change adds complexity: You'll need to specify
semantics to what happens if the list of extensions is
not there, or if it is incorrect, or if you use exten
Since it seems no one has replied yet, I'd agree that this would make
implementations easier. Iterating via a regular expression seems ugly
and hard to do (well except in Perl). :-\
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Se
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.
Imagine if I install WordPress (or insert other app here
26 matches
Mail list logo
