[OpenID] Using Account Creation Date to preempt recycleable OpenID's in v.next

Santosh Rajan santrajan at gmail.com
Thu Dec 3 18:23:05 UTC 2009


Thats a good question. I thought I had a good answer, but now you got me
thinking again.


On Thu, Dec 3, 2009 at 10:53 PM, John Panzer <jpanzer at google.com> wrote:

> So I have a lot of sympathy for the technical argument for oid: (or
> whatever).  And if starting from a blank slate that might be what I'd argue
> for too.  But with the existing practice it's hard argue for breaking
> changes, and additionally it seems to be very hard to get any new scheme
> registered.  In particular acct: is no sure thing (we can go rogue and use
> it unregistered of course), and it can be justified only because no existing
> scheme is appropriate, and we have a context where we need a URI.
>
> So I think the major question oid: would have to answer is, why aren't a
> collection of existing schemes (http:, https:, acct:, ...) sufficient?
>
> --
> John Panzer / Google
> jpanzer at google.com / abstractioneer.org / @jpanzer
>
>
>
> On Thu, Dec 3, 2009 at 7:41 AM, Santosh Rajan <santrajan at gmail.com> wrote:
>
>> Hi John Panzer, John Bradley,
>>
>> (I had to emphasize the surnames bcos both are John's).
>>
>> I was really looking at OpenID registering its own "oid:" scheme which I
>> have posted about earlier. OpenID today is in a position to be a universal
>> identity for everyone, provided we are able to accommodate everyone (or
>> atleast a large majority) in our "scheme" of things.
>>
>> Of course there are a lot of problem's on the way to solve, including the
>> "fragment" part of the OpenID.
>>
>> It is not that I don't like the "acct:" scheme idea. Unfortunately it
>> restricts itself to email like identifiers.
>>
>> I have a strong feeling that w3c will have to allow for a scheme for
>> "Identity Identifiers". And I would rather it be an OpenID defined scheme
>> like "oid:", rather than the "acct:" scheme, unless of course the "acct:"
>> scheme is willing to accommodate other type of URI's.
>>
>> At the end of the day, it is not us, but the user who wins. And we should
>> allow for the user to decide for himself ,whatever scheme he would like to
>> use.
>>
>> I really think we should take this matter to w3c for a scheme for
>> "identity identifiers". It does not matter what the scheme is called "oid:"
>> or whatever, what matters is that there is a IANA scheme for identity
>> protocols to follow.
>>
>> Thanks
>> Santosh
>>
>>
>> On Thu, Dec 3, 2009 at 6:20 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>
>>> Most URI schemes support fragments.    I am guessing that acct: could
>>> support fragments.
>>>
>>> Are you planning on registering the scheme?
>>>
>>> Are you thinking that Acct: will be used only for meta-data lookup, or
>>> for the claimed_id as well.
>>>
>>> By changing account recycling detection to be a separate parameter we are
>>> creating a significant breaking change that effects applications account
>>> logic as well as the openID library.
>>>
>>> I think openID's use of fragment is compatible with semantic web's use.
>>> Though that is more coincidence than design.
>>>
>>> https://ve7jtb.startssl.com/#123  becomes a identifier for me rather
>>> than the profile page.
>>>
>>> We need to carefully consider things that may be breaking changes.
>>>
>>> Another issue we need to address is migrating people from http:
>>> identifiers at RP.
>>>
>>> With RP's normalizing to http: and OP's not redirecting to the https
>>> version we are providing much lower security to people than we could be.
>>>
>>> Perhaps moving people to Acct: type identifiers where discovery is more
>>> secure, is part of the solution.
>>>
>>> However we do have a real problem with the installed base.
>>>
>>> John B.
>>> On 2009-12-03, at 12:45 AM, John Panzer wrote:
>>>
>>> > #1 is an extremely good point.  'Acct:' Webfinger identifiers do not
>>> > currently allow fragments for example.
>>> >
>>> > On Wednesday, December 2, 2009, Santosh Rajan <santrajan at gmail.com>
>>> wrote:
>>> >> Oops resending to specs.
>>> >>
>>> >> On Thu, Dec 3, 2009 at 8:07 AM, Santosh Rajan <santrajan at gmail.com>
>>> wrote:
>>> >>
>>> >> Hi Allen,
>>> >> It is just that i thought using fragments are less than optimal for
>>> recycled accounts.1) If we are looking at OpenID's as more than just http
>>> URI's, possibly any other URI, this could complicate matters.
>>> >>
>>> >> 2) Unfortunately fragments just don't look good when printed.3) Also
>>> the usage of fragments in OpenID does not reflect the true meaning of
>>> fragments. Fragments are used to denote different avatars of the "same
>>> entity", as in the semantic web. Or different parts of the same document as
>>> in html usage. However for OpenID we are using fragments to denote an
>>> entirely different entity, an new recycled account.
>>> >>
>>> >>
>>> >> If there are privacy concerns for using the account creation date i am
>>> open to using some thing else instead. But the idea was to avoid fragments
>>> by adding an extra parameter in the protocol, rather than in AX.
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Dec 3, 2009 at 1:04 AM, Allen Tom <atom at yahoo-inc.com> wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Hi Santosh,
>>> >>
>>> >> Section 11.5.1 in the OpenID 2.0 spec specifically mentions using
>>> fragments to differentiate between different users in the event that the
>>> OpenID URL is recycled.
>>> >>
>>> >> http://openid.net/specs/openid-authentication-2_0.html#identifying
>>> >>
>>> >> Large identity providers often try to free up desirable userids by
>>> recycling ids that are inactive.
>>> >>
>>> >> I do agree that account creation date is very useful to RPs, and
>>> several RPs have asked us to make the user’s account creation date available
>>> via Attribute Exchange. RPs that ask for this are usually interested in
>>> using the account’s tenure for anti-abuse purposes. The Yahoo OP will be
>>> making the account creation date available via AX early next year.
>>>  Hopefully we can have a standard schema for this.
>>> >>
>>> >>
>>> >> Allen
>>> >>
>>> >>
>>> >>
>>> >> On 12/1/09 8:32 PM, "Santosh Rajan" <santrajan at gmail.com> 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
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> http://hi.im/santosh
>>> >>
>>> >>
>>> >>
>>> >
>>> > --
>>> > --
>>> > John Panzer / Google
>>> > jpanzer at google.com / abstractioneer.org / @jpanzer
>>> > _______________________________________________
>>> > specs mailing list
>>> > specs at lists.openid.net
>>> > http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>
>>
>> --
>> http://hi.im/santosh
>>
>>
>>
>


-- 
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091203/461ca628/attachment.htm>


More information about the specs mailing list