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
