What is delegation for? (was Re: Wrapping Up Proposals)

[Kevin Turner]

On Mon, 2006-10-02 at 22:52 -0700, Drummond Reed wrote:
> Although it's easy to dismiss the privacy issue, there *can* be use
> cases under which an end-user may not want to reveal to their IP the
> identifier they present to the RP.

The problem is, the mapping of RP-facing-identifier to
IdP-facing-identifier is specified in a world-readable document.  No,
the IdP doesn't know where that document is, but in the age of Google,
it's likely to be indexed somewhere anyway.  Given that, it's not only
possible to find that information, it's probably not even expensive to
do so.

Here are the disadvantages I see to this proposal:

1) Currently IdPs do not know if they are delegating or not, and they
have to answer the request either way.  But under the new system, IdPs
will be able to distinguish a delegated request, and can at that time
say "hi, this is a premium feature.  Please insert two tokens to
continue this transaction, or watch this infomercial."  They'd do this
because if you're using a delegated identifier, you're not wearing an
identifier that is pushing their brand in public.  That may actually
make the IdP market healthier, but it's a little more restrictive for
the user.

2) Since IdPs don't currently know if they are delegating, they don't
have to understand syntax or discovery mechanisms for delegated
identifiers.  This means that I could actually use LJ as my IdP for my
i-name -- at least until Brad caught wind of it and suspended my account
for inappropriate use of system resources.  ;)  (Just kidding, I think.
Brad wouldn't *really* suspend an account for using XRI, right?)

However, when I weigh those losses -- which, as Josh describes them,
were probably more accidental features than motivating design cases --
against the mass of confusion this change would remove from the
protocol, I think the proposal presents a net gain overall.