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 <[email protected]> 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 > [email protected] / abstractioneer.org / @jpanzer > > > > On Thu, Dec 3, 2009 at 7:41 AM, Santosh Rajan <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> wrote: >>> >> Oops resending to specs. >>> >> >>> >> On Thu, Dec 3, 2009 at 8:07 AM, Santosh Rajan <[email protected]> >>> 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 <[email protected]> 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" <[email protected]> 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 >>> > [email protected] / abstractioneer.org / @jpanzer >>> > _______________________________________________ >>> > specs mailing list >>> > [email protected] >>> > http://lists.openid.net/mailman/listinfo/openid-specs >>> >>> >> >> >> -- >> http://hi.im/santosh >> >> >> > -- http://hi.im/santosh
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
