The WordPress User Problem (WAS: RE: Specifying identifier recycling)
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) 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 data, or I'm using an extension which stores the fragments in /tmp/ and they get blown away. I now no longer have access to my accounts on all the relying parties I've visited. Now what do I do? We can't count on each RP implementing an account recovery mechanism; remember OpenID outsources account management so you can focus on building you application. I can't call up my service provider and ask them to fix it, since well I was using my own provider. I could try to call up my webhost and see if they can restore from a backup, but I'd guess by the time I realize what that check box in my WordPress extension settings did there may not even be backups anymore. In the end, I'd be extremely frustrated that OpenID didn't work for me and I'd write a really obnoxious blog post about how much OpenID sucks. So while we solve one aspect of the recycling problem, we end up creating a larger problem from the opposite side of the equation. I'm certainly not arguing that we shouldn't solve this problem, nor that participation from large providers isn't vital, but would hate to see us create a problem for all of the people out there that have really helped gain OpenID traction. 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 display though used as a unique key. We do however need to address how a RP should handle display and account management differences when a fragment changes. I'm guessing it is unreasonable to expect every instance of https://davidrecordon.com to be replaced with https://davidrecordon.com/#231hwqai21jb when the fragment changes (not to mention that the fragment *must* remain private between the OP and RP to be effective). An extension is then written describing fragment usage from the OP perspective with huge warnings about how it should only be used by large service providers who know what they're doing. 2) We use a centralized canonical id approach like i-numbers. Basically somebody issues unique and never reassigned ids. 3) We use a distributed canonical id approach. Providers issue an ugly non-reassignable URL which points at the pretty one and vice-versa. Thus https://davidrecordon.com says its canonical is https://12jbd9210.pip.verisignlabs.com which in turn says it is https://davidrecordon.com. We could even kill two birds with one stone and use link rel='me' / to do this and setup an easy way to create identifier equality. 4) We use public/private key pairs, though this has the traditional private key revocation 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 recycling 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 solve this issue. But the issue was deemed important enough to be one of the only two on the 2.0 agenda. As concerns with the fragment proposal have been raised, which had the most agreement at IIW, it seems we no longer have consensus. I haven't seen many actually; checking this thread for what can count as concerns reveals only: a) Josh's initial email b) Johannes' +1 to not adopting a solution that doesn't actually work c) David acknowledging the concerns This doesn't seem to me to carry enough weight to veto the fragment proposal, especially when a) has been / can still be addressed, and the fragment proposal made sense to a dozen people at that meeting. As seen in this thread, there are a wide variety of opinions as to how to resolve this concern. I thus think merely picking one for the sake of putting something into 2.0 would be misguided. True, there have been a few (I definitely wouldn't call it a wide variety) possible solutions mentioned, but none very well defined, and none had the support of 10+ people like the fragment did. I have argued that it will have to be core (whether 2.0 or 3.0). I guess we should ask ourselves then if we really want this addressed in 2.0, and
RE: Auth 2.0 Extensions: Namespace Prefixes
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 Sent: Monday, April 30, 2007 12:48 PM To: specs@openid.net Subject: Auth 2.0 Extensions: Namespace Prefixes As currently defined, an extension has a global namespace URI as well as a request-local alias/prefix. For an extension with the namespace http://example.com/blah that has a field foo, the following fields are to be sent: openid.ns.blah=http://example.com/blah openid.blah.foo=bar It seems to me that the only way to discover the extension namespaces used in a particular message is to iterate over all keys looking for openid.ns.(\w+) and then see if the value matches. This seems ugly since usually webapps deal with such arguments as a dictionary structure, and use dictionary dicipline while interrogating the values. If we added an extra field: openid.extensions=blah,sreg,ax then the extensions used in a message would be accessible by splitting that field on its commas and then accessing openid.ns.whatever for each one. It's still not ideal, of course; it'd be better if the full namespace URI were included in the key part of a (key,value) pair, but many frameworks[1] can't deal with wacky punctuation characters in the key. [1] I'm looking at you, PHP. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Auth 2.0 Extensions: Namespace Prefixes
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 extensions without declared namespaces, etc. But if it still is needed, I'd propose, since the list of extensions is meta info, it should itself be an extension. openid.ns.ext=some:fixed:uri openid.ext.namespaces=ns1,ns2,ns3 openid.ns1.foo=... openid.ns1.bar=... openid.ns2.foo=... This makes processing cleaner and it also makes it possible for future specification of extensional behavior (sounds very Sartre ;) openid.ext.policy=... openid.ext.foo=... -Hans [1] I'm looking at you HttpServletRequest.getParameterMap() -Original Message- From: [EMAIL PROTECTED] on behalf of Recordon, David Sent: Tue 6/5/2007 8:00 AM To: Martin Atkins; specs@openid.net Subject: RE: Auth 2.0 Extensions: Namespace Prefixes 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 Sent: Monday, April 30, 2007 12:48 PM To: specs@openid.net Subject: Auth 2.0 Extensions: Namespace Prefixes As currently defined, an extension has a global namespace URI as well as a request-local alias/prefix. For an extension with the namespace http://example.com/blah that has a field foo, the following fields are to be sent: openid.ns.blah=http://example.com/blah openid.blah.foo=bar It seems to me that the only way to discover the extension namespaces used in a particular message is to iterate over all keys looking for openid.ns.(\w+) and then see if the value matches. This seems ugly since usually webapps deal with such arguments as a dictionary structure, and use dictionary dicipline while interrogating the values. If we added an extra field: openid.extensions=blah,sreg,ax then the extensions used in a message would be accessible by splitting that field on its commas and then accessing openid.ns.whatever for each one. It's still not ideal, of course; it'd be better if the full namespace URI were included in the key part of a (key,value) pair, but many frameworks[1] can't deal with wacky punctuation characters in the key. [1] I'm looking at you, PHP. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Generalized solution to OpenID recycling (was RE: The WordPress User Problem)
David Recordon wrote: snip of explanation of problems with fragment solution to OpenID recycling 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 display though used as a unique key. We do however need to address how a RP should handle display and account management differences when a fragment changes. I'm guessing it is unreasonable to expect every instance of https://davidrecordon.com to be replaced with https://davidrecordon.com/#231hwqai21jb when the fragment changes (not to mention that the fragment *must* remain private between the OP and RP to be effective). An extension is then written describing fragment usage from the OP perspective with huge warnings about how it should only be used by large service providers who know what they're doing. 2) We use a centralized canonical id approach like i-numbers. Basically somebody issues unique and never reassigned ids. 3) We use a distributed canonical id approach. Providers issue an ugly non-reassignable URL which points at the pretty one and vice-versa. Thus https://davidrecordon.com says its canonical is https://12jbd9210.pip.verisignlabs.com which in turn says it is https://davidrecordon.com. We could even kill two birds with one stone and use link rel='me' / to do this and setup an easy way to create identifier equality. 4) We use public/private key pairs, though this has the traditional private key revocation issues. I think my preference is #3, though I'm sure it has its own issues. David, first I just want to point out that XRI i-numbers are no more centralized than DNS, so I don't think there's any difference between #2 and #3 other than #2 uses XRI registries and #3 uses DNS registries. Second, I agree with you that the better architectural approach to the OpenID recycling problem is to provide a standard reassignable-to-persistent synonym mapping capability that will work for both URLs and XRIs (and even URNs). This solves the problem by allowing *any* reassignable identifier (either a URL, or an XRI i-name) to be mapped to *any* persistent identifier (either a persistent URL, an XRI i-number, or even a resolvable URN). The fragment solution is in fact just a special case of this architecture, i.e., it maps a URL-without-a-fragment (reassignable) to the-same-URL-with-a-fragment (persistent). It does have some special issues due to the use of URL fragments vs. other components of a URI, but otherwise it is just one option that could be implemented to map a reassignable to a persistent identifier. 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-to-persistent synonym mapping problem and thus has explicit syntax for reassignable and persistent identifiers), there is nothing to prevent CanonicalID mapping from being done with URLs. Discussion on this thread so far has only entertained using this mechanism to handle reassignable-URL to persistent-XRI mapping, however there's nothing to prevent it being used for reassignable-URL to persistent-URL mapping, or even reassignable-URL to persistent-URN mapping (as long as the URN is resolveable, such as a Handle ID). Everything is already in place in XRDS architecture except the Canonical ID verification rules. The OASIS XRI TC has already published the reassignable-XRI-to-persistent-XRI Canonical ID verification rules in the first editor's draft of XRI Resolution 2.0 Working Draft 11 (a more detailed explanation of those rules will be in the second editor's draft due out tomorrow). Per Martin's suggestion, in the second editor's draft will also add the Canonical ID verification rules for reassignable-URL-to-persistent-XRI mapping. 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 approached it this way, all the OpenID Authentication 2.0 spec would need to do is specify the use of Canonical ID verification as part of the OpenID discovery process, and then everyone -- users, OPs, and RPs, would be able to use any reassignable-OpenID-identifier-to-persistent-OpenID-identifier mapping process that worked best for them. Thoughts? =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The WordPress User Problem (WAS: RE: Specifying identifier recycling)
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. This concern is definitely something new; I haven't seen it expressed before. 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 data, or I'm using an extension which stores the fragments in /tmp/ and they get blown away. I now no longer have access to my accounts on all the relying parties I've visited. Now what do I do? What do you do today, if you forget your slashdot password and slashdot didn't implement account recovery? Most (if not all) RPs today do implement account recovery - they don't want to loose users, and they know users make mistakes and forget passwords. We can't count on each RP implementing an account recovery mechanism; remember OpenID outsources account management so you can focus on building you application. I can't call up my service provider and ask them to fix it, since well I was using my own provider. You should call up your OP then. I could try to call up my webhost and see if they can restore from a backup, but I'd guess by the time I realize what that check box in my WordPress extension settings did there may not even be backups anymore. In the end, I'd be extremely frustrated that OpenID didn't work for me and I'd write a really obnoxious blog post about how much OpenID sucks. So while we solve one aspect of the recycling problem, we end up creating a larger problem from the opposite side of the equation. I'm certainly not arguing that we shouldn't solve this problem, nor that participation from large providers isn't vital, but would hate to see us create a problem for all of the people out there that have really helped gain OpenID traction. 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 display though used as a unique key. We do however need to address how a RP should handle display and account management differences when a fragment changes. I'm guessing it is unreasonable to expect every instance of https://davidrecordon.com to be replaced with https://davidrecordon.com/#231hwqai21jb when the fragment changes (not to mention that the fragment *must* remain private between the OP and RP to be effective). An extension is then written describing fragment usage from the OP perspective with huge warnings about how it should only be used by large service providers who know what they're doing. I believe it could work with REQUIREments in the core for RPs (discovery, verification), and OPTIONAL / extension for the OPs. Though the gained simplicity I think would be minimal. But if the other advantage is that OPs don't carelessly implement this feature without knowing what they are doing, then it may be better overall. Totally agree with the warnings / raising awareness that identifier recycling is an advanced feature. I believe this is part of a more general problem: by being decentralized, OpenID gives power to everyone (anyone can be an OP); while being an RP is / should be simple, doing the OP job right is not. 2) We use a centralized canonical id approach like i-numbers. Basically somebody issues unique and never reassigned ids. 3) We use a distributed canonical id approach. Providers issue an ugly non-reassignable URL which points at the pretty one and vice- versa. Thus https://davidrecordon.com says its canonical is https://12jbd9210.pip.verisignlabs.com which in turn says it is https://davidrecordon.com. We could even kill two birds with one stone and use link rel='me' / to do this and setup an easy way to create identifier equality. I think my preference is #3, though I'm sure it has its own issues. Do you have a more detailed proposal on how this would work? I do see a couple important / possibly show-stopper issues here, but I haven't really explored this direction for a solution. If you have, I would definitely be interested to learn more. However, I still believe #1 is our best bet, if we can focus our efforts to make it work in such a way to address your grassroots adoption concerns. #1 did have (and still has, I hope) the support of a good many people, and has a concrete and detailed proposal. If we agree that _some_ changes to the core are required, then #1 has also the time advantage. 4) We use public/private key pairs, though this has the
Re: Auth 2.0 Extensions: Namespace Prefixes
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 be the case
where an extension had a namespace alias declaration but was missing
from that list, or was in that list but did not have a namespace alias
declaration.
Iterating one time to build a lookup table is easy, and you get the
namespace URIs out of that one iteration. It doesn't take regular
expressions (it's just a prefix match), and I've never used a language
that would make this kind of iteration difficult.
Each technique implemented in Python for comparison:
prefix = openid.ns.
prefix_len = len(prefix)
def extractNamespaceAliases(query):
Extract the namespace URIs from a dictionary containing a
parsed HTTP query string or POST body. Returns a dictionary from
namespace alias to namespace URI.
This code implements the current draft of the OpenID 2.0
specification. Very straightforward.
namespace_aliases = {}
for k, v in query.iteritems():
if k.startswith(prefix):
alias = key[prefix_len:]
namespace_aliases[alias] = v
return namespace_aliases
def extractNamespaceAliases1(query):
Extract the namespace URIs from a dictionary containing a
parsed HTTP query string or POST body. Returns a dictionary from
namespace alias to namespace URI.
This version implements the proposal in this thread. The code has
more branches and has to build new strings as lookup keys.
namespace_aliases = {}
namespace_string = query.get('openid.extensions')
# Ignore missing or empty openid.extensions parameter
if namespace_string:
aliases = namespace_string.split(',')
for alias in aliases:
try:
namespace_aliases[alias] = query[prefix + alias]
except KeyError:
pass # Ignore declared but missing extensions
return namespace_aliases
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: Generalized solution to OpenID recycling (was RE: The WordPress User Problem)
=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-to-persistent synonym mapping problem and thus has explicit syntax for reassignable and persistent identifiers), there is nothing to prevent CanonicalID mapping from being done with URLs. Discussion on this thread so far has only entertained using this mechanism to handle reassignable-URL to persistent-XRI mapping, however there's nothing to prevent it being used for reassignable-URL to persistent-URL mapping, or even reassignable-URL to persistent-URN mapping (as long as the URN is resolveable, such as a Handle ID). Everything is already in place in XRDS architecture except the Canonical ID verification rules. The OASIS XRI TC has already published the reassignable-XRI-to-persistent-XRI Canonical ID verification rules in the first editor's draft of XRI Resolution 2.0 Working Draft 11 (a more detailed explanation of those rules will be in the second editor's draft due out tomorrow). Per Martin's suggestion, in the second editor's draft will also add the Canonical ID verification rules for reassignable-URL-to-persistent-XRI mapping. 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. I think that URL-to-URL is more useful in the short term, because (unless something's changed since we last talked) you can't currently get an i-number without purchasing an i-name. This does, however, raise a transitional issue: as soon as providers start publishing CanonicalID, all of the existing accounts are effectively broken because the primary key is being changed.[1] If LiveJournal were to suddenly start publishing in the XRDS for http://frank.livejournal.com/ that the CanonicalID were http://www.livejournal.com/u/3449 (for example) frank would lose his account on any site he had already been using. For this to work out, RPs would have to change to retaining a list of synonyms rather than simply keying off the CanonicalID, but then that defeats the object of creating the ability for identifiers to be recycled. The only solution which springs immediately to mind is to get all of the big OP players to implement this and then have the burden be on RPs to handle the migration from the old display identifiers to the new CanonicalIDs as they transition from 1.1 to 2.0. This only works if things are changed in a particular order, though. I'm attracted to the cleanliness of using the same CanonicalID mechanism for both URLs and XRIs and any combination of the pair, but unless the above can be resolved I don't think it's workable. [1] This issue exists for the fragment approach too, but with the obvious solution that you simply don't starting appending a fragment until an identifier enters its second generation. This solution is not appropriate for CanonicalID because it has more broad semantics than simply identifying the generation number of the identifier. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Auth 2.0 Extensions: Namespace Prefixes
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 openid.ns.* or splitting the value of openid.extensions and then iterating through the result seems roughly equivalent. Our implementation builds a map of extension aliases to namespaces when a message is received and after that, at any point during the life cycle of that message, extensions queries are simple and quick map lookups. So I'd rather not add the openid.extension field. For what it's worth, I'm no longer in favour of my own proposal. :) It was ill-thought-out and does not solve the problem I set out to solve. My intention was to create a situation where the question of Is extension x used in this request requires a single dictionary lookup, which the extensions field does not solve. Since that is not really workable without moving away from the use of URIs to identify extensions, I'm happy to accept this small wart for the sake of keeping things sane and simple. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The WordPress User Problem (WAS: RE: Specifying identifier recycling)
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 data, or I'm using an extension which stores the fragments in /tmp/ and they get blown away. I now no longer have access to my accounts on all the relying parties I've visited. Now what do I do? 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 *nothing* if you control the base identifier (to the point that you can choose an OpenID provider). I'm not arguing for or against a particular approach here, but I think your argument is flawed. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Generalized solution to OpenID recycling (was RE: The WordPress User Problem)
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 approached it this way, all the OpenID Authentication 2.0 spec would need to do is specify the use of Canonical ID verification as part of the OpenID discovery process, and then everyone -- users, OPs, and RPs, would be able to use any reassignable-OpenID-identifier-to-persistent-OpenID-identifier mapping process that worked best for them. Not knowing how you plan to have the canonical ID verification for URLs (really looking forward to reading tomorrow's draft), I'm not sure it's a simpler approach or even a generalization of the fragment proposal. Yes, it would be simpler to specify in the OpenID spec, but it would include a pointer to a section of the XRI spec, which scares so many people away. From your comments I understand that the persistent identifier has to be discoverable; in the fragment approach, the fragment itself (which is the actual persistent part) is stripped out at discovery time, and only comes into play at the auth response / verification stages (hence not sure the generalization applies). Keying your identity on a new / different URL also brings in the management effort required to maintain that second, persistent URL (and making sure it stays persistent). If that is an absolute URL, the cost is considerably higher than just keeping track of your persistent fragment. (In this respect the fragment approach is simpler.) Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Auth 2.0 Extensions: Namespace Prefixes
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 value of openid.extensions and then iterating through the result seems roughly equivalent. Fair enough. I guess the question is: Is the cost of semantical additions (as I outlined) worth such a minor improvement in processing? -Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Auth 2.0 Extensions: Namespace Prefixes
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 value of openid.extensions and then iterating through the result seems roughly equivalent. Our implementation builds a map of extension aliases to namespaces when a message is received and after that, at any point during the life cycle of that message, extensions queries are simple and quick map lookups. So I'd rather not add the openid.extension field. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The WordPress User Problem (WAS: RE: Specifying identifier recycling)
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 WordPress, or an upgrade blows away my OpenID extension data, or I'm using an extension which stores the fragments in /tmp/ and they get blown away. I now no longer have access to my accounts on all the relying parties I've visited. Now what do I do? 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 have lost it and are no longer able to log into any RPs. (Unless there's an account recovery mechanism either on the RP or the OP.) The RPs know it, but are not supposed to display / disclose it. You might choose to use a fragment if you have acquired a recycled identifier, but you can choose the fragment. It protects *nothing* if you control the base identifier (to the point that you can choose an OpenID provider). Agreed - if you loose control over the URL, you can no longer use your old online identity. However, the issue / feature this does address is protect your RP accounts if you loose your identity. (The new owner of davidrecordon.com would not be able to sign into the old davidrecordon.com's digg account.) Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)
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 *nothing* if you control the base identifier (to the point that you can choose an OpenID provider). Isn't this a core flaw with the fragment approach? That if you lose control of the base identifier, you lose control of any fragment? Wouldn't it be fairly easy -- precisely because the fragment is not secret -- for the party that takes over the base identifer to discover the fragment(s) that have been used earlier, and thus for the new owner to then be able to spoof any fragment that has been issued? 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? =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)
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? Enabling recycling for large sites that control their own identifiers was the use case that was declared mandatory to cover for the OpenID 2.0 specification. I would personally like to have a solution that protects identifiers without a central manager, but that is not the case that is holding up OpenID 2.0. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Questions about IIW Identifier Recycling Table
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? 2.) Ditto For URL+Token (I assume this means a public vs. private token?) 3.) What does DE mean in the Does not require change to DE? 4.) In the Stolen OP account header, it appears that all 4 of the proposed methods have problems. However do we really want an identifier to be recycled if an account is stolen ( i.e., what if an account is only stolen for a brief period, but then recovered?) 4.) What is Active Recycling? 5.) In the New DB Field header, doesn't an OP/RP need a new DB field in the fragment scheme, in order to distinguish between the id and the current fragment? Or does the OP/RP simply store the whole URL (fragment included) and parse as necessary? 6a.) What is MO in MO Strip Fragment? 6b.) What does the MO Strip Fragment header mean in general? Thanks! David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The 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 is never available, then there is confusion about which user of an identifier is responsible for content that has been posted. One use case where software agents having access to the fragment is particularly important is if the identifier is used for access control, and the access control list is retrieved from off-site (e.g. from a social networking site). The implementation that seems most sane is for places that display the identifier for human reading look like: a href=http://josh.example.com/#this-is-intended-for-machine- consumption http://josh.example.com//a so that the software agent would see the fragment, but the user wouldn't have to. On 5-Jun-07, at 2:55 PM, Recordon, David wrote: 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, though also doesn't solve one of the other aspects of identifier recycling. I thought so too, but I believe Josh is right - the lost domain cell with an X in it (for URL + public fragment) supports Josh's statement: http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling So if we're not dealing with this use case, it becomes actually simpler to address just the identifier recycling for big OPs, where loosing the domain is not an issue. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: The WordPress User Problem (WAS: RE: Specifying identifier recycling)
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 the pretty one. I know I need to write this up more... --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 05, 2007 3:18 PM To: Recordon, David Cc: Josh Hoyt; Johannes Ernst; OpenID specs list Subject: Re: The 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 is never available, then there is confusion about which user of an identifier is responsible for content that has been posted. One use case where software agents having access to the fragment is particularly important is if the identifier is used for access control, and the access control list is retrieved from off-site (e.g. from a social networking site). The implementation that seems most sane is for places that display the identifier for human reading look like: a href=http://josh.example.com/#this-is-intended-for-machine- consumption http://josh.example.com//a so that the software agent would see the fragment, but the user wouldn't have to. On 5-Jun-07, at 2:55 PM, Recordon, David wrote: 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, though also doesn't solve one of the other aspects of identifier recycling. I thought so too, but I believe Josh is right - the lost domain cell with an X in it (for URL + public fragment) supports Josh's statement: http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling So if we're not dealing with this use case, it becomes actually simpler to address just the identifier recycling for big OPs, where loosing the domain is not an issue. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)
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 is the main use case for it). I'm happy to help with the writeup -- I've already spent a not-insignificant portion of my lifespan dealing with this issue ;-) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Tuesday, June 05, 2007 3:50 PM To: Johnny Bufu Cc: OpenID specs list Subject: RE: The WordPress User Problem (WAS: RE: Specifying identifierrecycling) 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 the pretty one. I know I need to write this up more... --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 05, 2007 3:18 PM To: Recordon, David Cc: Josh Hoyt; Johannes Ernst; OpenID specs list Subject: Re: The 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 is never available, then there is confusion about which user of an identifier is responsible for content that has been posted. One use case where software agents having access to the fragment is particularly important is if the identifier is used for access control, and the access control list is retrieved from off-site (e.g. from a social networking site). The implementation that seems most sane is for places that display the identifier for human reading look like: a href=http://josh.example.com/#this-is-intended-for-machine- consumption http://josh.example.com//a so that the software agent would see the fragment, but the user wouldn't have to. On 5-Jun-07, at 2:55 PM, Recordon, David wrote: 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, though also doesn't solve one of the other aspects of identifier recycling. I thought so too, but I believe Josh is right - the lost domain cell with an X in it (for URL + public fragment) supports Josh's statement: http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling So if we're not dealing with this use case, it becomes actually simpler to address just the identifier recycling for big OPs, where loosing the domain is not an issue. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
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 was compromised is orthogonal to its use purely as an identifier, i.e., as Johannes points out, if the private key was compromised, use of the public key could revert to the role of serving purely as an identifier, and another set of credentials (such as another public/private key pair) could be assigned. 3) In this light, the primary drawbacks I see to public keys as identifiers are: a) They are typically much larger than other persistent identifiers designed for this purpose (e.g., XRI i-numbers as issued by XDI.org or Handles as issued by CNRI). b) I am not aware of a resolution protocol designed for them, with the exception that I believe syntactially they could be used as XRI i-numbers. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Tuesday, June 05, 2007 7:27 PM To: =nat Cc: '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? You allow for this for non-public-key credentials but not for others ... But I don't want to perpetuate this thread given the general reluctance of the community to think about public key cryptography at this time ... I just want to go on record that I find the arguments made counter public keys on this thread non-persuasive and want to pick it back up when the community is ready to go there ... (note also that the security industry would not exist in the shape it does if we didn't have public key crypto, so that technology does contribute something somewhere ... perhaps also to OpenID?) Just follow the following argument ... let's assume that the problem that started this thread ... can be solved by adding a number to the URL identifier (using a fragment syntax or an i-number or whatever other approaches were discussed) ... then it also can be solved by adding a large number instead of just any number ... then it also can be solved by adding a large number that could be a public key, which is nothing but a large number ... which, therefore, makes a public-key-based approach at least as powerful as a plain number Just some stuff for thought ... ;-) Cheers, Johannes. On Jun 5, 2007, at 17:58, =nat wrote: 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 loose your credit card and replace it. Doing so has not nullished your identity. You still are yourself. Your identity itself and the attribute associated with it apart from this particular lost credential data (whether it was a password or credit card) stays intact. This picture changes dramatically when you use public key as your main identity address. If you lose your private key, that's the end of story. Your relationships with all the RPs are ruined. That is why I believe that we should not be using this kind of public key as the identification data for RPs. Also, mandating OPs to specify a unique opaque string as the identification data would be much simpler than requiring parties to do public key 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 To: =nat Cc: 'OpenID specs list' Subject: Re: Specifying identifier recycling I would postulate that if you want to be able to prove your identity, you cannot allow your credential to be lost, interpreting credential to be all the information that bears onto establishing your identity. (saying it this way, it is a tautology.) This is independent of whether anybody uses public keys, or any other technology. So I very strongly suspect that while it may be more apparent to you guys that the issue exists for public key technology, it also exists for all other approaches, whether we know them at this time or not! However, I can readily see that strong voices (that'd be you guys ;-)) are not ready to adopt any kind of public key technology into the OpenID family, never mind whether X or Y wins this particular argument. So we don't need to continue this thread. I continue to believe, however, as I have said before, that we don't have enough of an agreement on the
