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

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

specs mailing list

Reply via email to