Why is the lack of a generational identifier on your Google Profiles claimed identifier an issue? You're the first one to claim that identifier. When it gets recycled, Google can tack on a #fragment on its claimed_ids for that same URL and thereby let RPs know it's a new user.
Am I missing something? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Wed, Dec 2, 2009 at 11:21 AM, John Panzer <[email protected]> wrote: > John- I can't tell if your profile path ID is an opaque Google-generated > string or a GMail namespace readable identifier :) > > +Breno. Not sure what the plan is here myself. > > -- > John Panzer / Google > [email protected] / abstractioneer.org / @jpanzer > > > > On Wed, Dec 2, 2009 at 10:41 AM, John Bradley <[email protected]> wrote: > >> Interesting, >> >> I just tried my google contact page: >> >> openid.claimed_id: http://www.google.com/profiles/ve7jtb >> openid.identity: http://www.google.com/profiles/ve7jtb >> >> It is not supporting the existing method of identifier recycling via >> fragments. >> That wasn't required for the PPID type identifiers because of the way they >> were constructed from teh account information. >> >> It is just my opinion, but I suspect google is creating a huge problem for >> itself if those pages are ever going to be recycled. >> >> Is adding a account creation date parameter and revising the protocol seen >> as a way out of this problem? >> >> They should have used generational fragments from the start. >> >> John B. >> >> On 2009-12-02, at 2:48 PM, John Panzer wrote: >> >> On Wed, Dec 2, 2009 at 7:47 AM, John Bradley <[email protected]> wrote: >> >>> Hi John, >>> >>> I thought and I might be wrong that Santosh was recommending sending a >>> timestamp of the account creation at the OP as a way to detect account >>> recycling. >>> >>> It sounds like you are looking for a timestamp of the transaction. >>> >>> That is contained in the Nonce if it is properly formatted and you want >>> to store all or part of it at the RP. >>> >>> >> Not quite. What I want to know is "when was this particular identifier >> last recycled?" (which in usually comes down to "when was this identifier >> last registered with this OP ", though delegation messes with that). >> >> Why I want to know this: Because I can store the value, and if it >> changes, I know that I'm dealing with a re-created account even if I didn't >> see a notification about an account deletion. This is extremely useful to >> me as an RP because I can then take measures to protect private data because >> the person at the terminal is no longer the same as they were before. >> >> Note that this also lets me see if an identifier is travelling backwards >> in time, which would indicate either an impersonation or an account recovery >> from an impersonation, both of which are very useful things to know about. >> Fragments don't help at all there. >> >> The Nonce doesn't help me as an RP here. >> >> >> >>> The original discussion on account recycling had two proposals one using >>> the CID from the XRDS and another I think from Yahoo (I may be wrong about >>> that) with the current OP derived fragment. >>> >>> I am guessing that the OP account creation date might be considered >>> private or sensitive information. >>> That is probably why they left it up to the OP to determine the format. >>> >> >> That's what I guessed. I think perhaps this could be mitigated with >> fuzzing -- don't recycle an identifier more than once per year, and only >> give out timestamps on year boundaries or something similar. And not having >> this info still leaves us vulnerable to incorrect correlations (e.g., >> thinking that someone said something on a mailing list a year ago because >> the archives don't store the fragment with the author's name). >> >> >>> >>> I can certainly see making the account creation date available via AX. >>> However making it optional won't work in the role of detecting account >>> recycling if the new user doesn't disclose the attribute. >>> >> >> This was also discussed (I believe proposed by Breno) in the context of >> reputation of an identifier. >> >> >>> >>> Requiring an attribute like that to be part of the base authentication >>> protocol is probably not ideal. >>> >>> I know that many RP's don't like having to strip the fragment from the >>> claimed_id before using it for display. >>> >>> On the other hand many of the openID's are encrypted string that convey >>> no meaningful information about the user (Google etc). >>> >> >> True, though that can change (optionally) now that Google Profiles are >> OpenIDs. >> >> >>> >>> We need to look at the larger picture regarding what RP's are storing as >>> identifiers. >>> >>> >> Agreed. >> >> >> >>> John B. >>> On 2009-12-02, at 12:20 PM, John Panzer wrote: >>> >>> > Santosh, John - >>> > >>> > I agree with the logic of Santosh's proposal however. A timestamp is >>> > sufficient, and it's also necessary when you want to correlate against >>> > other real world evidence (timestamps on authored documents, dns >>> > registry dates, timestamped log entries). I'm not sure what's gained >>> > by making it more general - is it precisely to avoid unwanted >>> > correlation? >>> > >>> > Also, since you only need to store one record at a time for an openid >>> > in a user Db, I don't think this needs to be part of the primary key - >>> > just a field that's checked against. Though personally I'd add a >>> > timestamp to my primary key indicating the local account creation >>> > date. Which brings me back to point #1 :). >>> > >>> > On Wednesday, December 2, 2009, John Bradley <[email protected]> >>> wrote: >>> >> Moving to Specs. >>> >> Santosh, >>> >> This is currently supported in openId 2.0 by the fragment portion of >>> the claimed_id. >>> >> The spec doesn't specify the format of the fragment, so it could be a >>> account creation date. >>> >> This is the current method the large OP's are using to support >>> identifier recycling.Some recycle thousands of IDs per day. >>> >> That is one reason why some of the large OPs don't support openID 1.1 >>> as there is no identifier recycling support in 1.1. >>> >> I have found RPs (some large) who are not storing the fragment as part >>> of there primary key because they want to use the claimed_id for display. >>> That is a bad idea. >>> >> Making the OP responsible for account recycling via the positive >>> assertion works OK for the large OP. >>> >> It doesn't work for delegation. >>> >> Ideally v.Next would also support a way for the user to prevent >>> someone else from taking over your claimed_id if you loose control of your >>> domain etc. >>> >> This is related to the question of claimed_id portability between OP. >>> >> RegardsJohn B.On 2009-12-02, at 1:32 AM, Santosh Rajan wrote: >>> >> I would like to first of all, apologies to all members of the >>> community, for having made comments that has caused distress on this list. >>> My apologies to all members. >>> >> >>> >> I am not aware if the idea of using account creation dates to preempt >>> recycleable identifiers has been considered before, and i thought it might >>> be a cheap way to preempt the problem, and worth looking into. >>> >> >>> >> All accounts have a logical creation date, a time stamp that in >>> combination with an account identifier will be universally unique. I think >>> all providers save this time stamp (or atleast the creation date) when the >>> account is created. Let us call this timestamp the "account timestamp". This >>> timestamp does not change through the life cycle of the identifier, and only >>> changes when a new account is created with the same identifier (recycled). >>> >> >>> >> 1) All OP's can return the account timestamp as an extra parameter >>> with every authentication response.2) Every time a user logs in at an RP, >>> the RP can verify that the timestamp has not changed. >>> >> 3) If the timestamp has changed, it means that this a recycled >>> identifier, and this is a new user. >>> >> >>> >> >>> >> -- >>> >> http://hi.im/santosh >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> general mailing list >>> >> [email protected] >>> >> http://lists.openid.net/mailman/listinfo/openid-general >>> >> >>> >> >>> > >>> > -- >>> > -- >>> > John Panzer / Google >>> > [email protected] / abstractioneer.org / @jpanzer >>> >>> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
