On 6/7/07, David Fuelling <[EMAIL PROTECTED]> wrote: > > I'm not sure I understand what's "public" about this. If I understand > > it correctly, from the relying party's perspective, the user's account > > is keyed off of the pair of the identifier and the token. This sounds > > like URL + private token in that table. Am I missing something? > > Maybe I don't understand the difference between private and public tokens. > My proposal used private information to create a public token that can be > sent via AX (thus the hybrid term). Am I understanding the difference > between private/public tokens incorrectly?
I think I see how we're using the term differently. The token only protects your identifier if the relying party does not ever display it. If the relying party did display it, anyone who gained control of your identifier in the future could just send that (reusable) token along with an assertion in order to gain access to a relying party. Since the relying party needs to keep the token secret, I was calling it "private." It's shared between the provider, the user, and the relying party, but it's secret from anyone else. I think it's also important to note that the transport mechanism for the token (using attribute exchange, as an extra field or as a fragment) is independent from whether the token should be shared. I think using attribute exchange for this core feature is a non-starter, since it would create a dependency on the attribute exchange in the authentication spec. > > This approach was rejected at IIW because: > > > > 1. An extra database field is required (whether or not the data is > > transmitted using attribute exchange) > > If the AX database schema is architected properly, then the addition of a > new AX attribute should not necessitate a new database column. If this were > the case, then AX would not really be feasible (how would an RP deal with a > new AX attribute?). If you have an existing application and you are adding OpenID support, in order to support the token, you would have to alter your schema. When creating a new application, it's not a big deal. I also expect that few relying parties will support *arbitrary* attributes, since the relying party will not be asking for attributes that do not have specialized uses anyway. Perhaps this deserves clarification on the wiki page. > > 2. There is no obvious way to tell if a user is the same user across > > sites (The identifier contains a secret portion) > > Good point. Although, let's assume that RP's display fragment-enabled > OpenID's in the following manner, which overcomes the "Fragments are Ugly" > problem: > <a href=" http://me.example.com#1234";>http://me.example.com</a> > > Users will not be able to easily distinguish that the OpenID is owned by a > different user without hovering over the URL in their browser. That said, > computers will be able to, since the actual HREF is what counts, I assume. > Has this been discussed wrt to fragments. There has been some discussion about it. It's a tough issue, and it's one of the reasons that I asked the (surprisingly controversial) question about whether we can just add the token to some part of the URL, if it's going to be publicly available anyway. If it's a visible part of the URL, both users and software agents will be able to tell the difference between identifiers. In the discussions that we have had about this issue so far, we have concentrated on a user gaining access (either on purpose or accidentally) to resources that were controlled by the previous owner of their identifier. For example, a user could sign in to a photo sharing site and see someone else's photos. A related issue is that of a third party mistaking resources controlled by the previous owner of a URL as being controlled by the current owner. For example, a potential employer does a search for the user's identifier and finds photos of some illegal activity, without the uniquifying token as a visible part of the URL. > > 3. Concern about depending on a secret for a user to be able to sign > > in to a site (David's Wordpress issue) > > I think DR had a problem with anything that could be lost, thereby > preventing access to an RP. Both Fragments and Tokens seem to suffer from > this problem, since in the Fragment scheme, if I or my OP forgets what my > fragment was, I won't be able to login to an RP without recycling my account > (or forcing an account recovery procedure). > > Seems like the odds of my OP losing my fragment information are pretty slim. > Identically, the odds of my OP losing my recycling_password are pretty > slim, too. What's more, If *I* lose my recycling password, why should I > care? Only the OP needs to deal with it, and perhaps the OP can just show > me that password in an account settings page when I login(?) If the token is publically viewable, then losing it is not an issue. I do not share David's concern about depending on a secret, since both the relying party and the provider already need to store secrets. I think it's also important to note that the hashing scheme that you detailed is not the only viable scheme for generating tokens. I think that it's a reasonable one, and I proposed a very similar one when discussing this at IIW, but I think that the argument for a secret token scheme is stronger if the details of how the secret tokens are generated is left up to the provider and user to work out. > > I'm not sure which of these issues were the basis for rejecting this > > approach. To me, the biggest problem with it is (2) > > I agree that #2 is a problem with the token approach. However, the fragment > approach doesn't solve the problem of a new OP domain owner being able to > make auth assertions for OpenID's that were created for a previous owner > (See my proposal #3). This seems to be an edge case, but its effects are > much more devastating than people not being able to visually (or otherwise) > determine who owns a given OpenID. Any approach where part of the identifier is secret is subject to this problem, regardless of whether it's a fragment or a separate token. I share your interest in solving the problem of preventing new owners of an identifier from making assertions as the previous owner, but I could not get sufficient support for a viable solution to this problem. At this point, my primary interest is in getting the OpenID authentication spec finalized, and if it does not include support for this particular use case, I think that's okay (we can add it in the next spec version). > Maybe the solution is use both approaches at the same time? :) I considered suggesting a hybrid public/private approach, but people thought that the private token approach was too complicated by itself, so I kept it to myself. I very much like the properties that this would have (the benefits of both), and the drawbacks of neither (AFAICT). It's possible to implement this as an extension. It wouldn't be as nice as making it required in the core spec, since there would be relying parties who would not implement it, but if it was adopted, it could make a big difference. I hope that in the future, extensions are where most of the OpenID innovations happen, and spec revisions are basically pulling in extensions that have proven themselves in the wild. Josh _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
