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

John Panzer jpanzer at google.com
Thu Dec 3 17:23:42 UTC 2009


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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091203/15cfec51/attachment-0001.htm>


More information about the specs mailing list