FW: [dix] thoughts on "identity" and IETF

["THOMAS, BRIAN M \(SBCSI\)" <bt0008 at att.com>]

Phill:

Sorry for the delay in responding; I left the office for the remainder
of the year after composing my previous message.  Happy new year!

[...and with the new year comes a new corporate identity and a new email
domain, which caused my post to be held the first time.  Thanks, John,
for the heads-up...]

> The problem with this approach is that it requires the user to do more

> than they are prepared to do which is vanishingly close to 'nothing at

> all'.

To the Win98 users who still find patching, backups, antivirus software
and firewalls too much effort, such is of little value, I will readily
concede, but I doubt that anything we can do will help them much.

But for the users who have clamored for this effort, I'm convinced the
problem is not mere laziness but confusion.  If you give the user direct
and visible control over concrete concepts that mean something to his
life, I think that you'll find that his view of what constitutes a
trivial task changes.  "Are you willing to give the local Burger Barn
restaurant your home address and phone number in exchange for getting
every thirteenth hamburger free?" is a far simpler and more concrete
question than "Are you willing to trust code from this provider?"  In
the first case, you must evaluate a relatively clear (and granular)
value choice:  decreased privacy versus cheaper junk food, clearly
specified; no esoteric concepts to ponder.  In the second, even as a
specialist in the field I find myself wishing for more information and
more choices.

Further, it needn't require a lot of effort; properly designed, it can
easily be arranged so that user interfaces only demand information you
haven't already given, and at all other times actually save effort.
Fill in a form?  How many times will I have to type my name, address,
phone number, SSN, account number, etc. etc. into a form for every new
vendor I deal with?  Even without other motive (or excuse), many
merchant web sites would keep that information just to keep me from
having to type it in every time I order something from them.  Reduce the
friction, right?

Even if you don't have any previous experience with a site, if all the
information they request carries tags from a namespace you've already
used, a tool could supply default values you had made generally
available, and ask about others.  If their namespace is unknown to you,
it could prompt for values from your own personal namespaces, possibly
preferring more likely values heuristically, and creating the mapping
for future use.

Of course, for vendors that you know, you can have profiles previously
saved that fill in all the fields based on your previously expressed
preferences, and get rid of the "remember me?" preference on their site.

All of these, however, are user interaction design decisions not
directly related to the specification we need to produce, but exemplify
the kinds of uses that should be supported.


> I am very skeptical about the assertion that the user wants to really 
> give out the information at all, or for that matter there is as much 
> interest in the data requested as the inferences that can be drawn 
> from it.

I'm not entirely sure I take your meaning, but I think that I agree -
and that it highlights some of the reasons that I have heard for
starting this effort:  that too often more information is given out than
we would like, and more than is strictly necessary to provide what we
want; and that more control over that information is deirable.

Remember that merely giving users the ability to do something doesn't
require them to do it; I can configure Firefox to dance and sing and act
strangely, but my wife and kids don't have any problems using it as
delivered.


> I agree people want flexibility, but this was the starting point for 
> SAML, GSSAPI, SASL. It is time to say 'choose one negotiation 
> infrastructure, the existence of 6 negotiation standards does not mean

> there is value to supporting more than one.

No argument here.  However, what we choose (or build) must begin with
agreement on the requirements.  Perhaps I have misunderstood where we
are in this process, but I haven't seen such a detailed statement of
requirements and have been under the impression that it doesn't yet
exist.

It is my belief, therefore, that what we must do is to specify a model
for expressing fine-grained user choices in their own terms, so that
implementors can provide products that translate those expressions into
equivalent action with their mechanisms of choice.  It is quite possible
that this is not actually a model but a metamodel, since the metadata
must be specifiable by the end-users.

Many ad-hoc efforts, both open and proprietary, are currently underway
in this area; I hope that we can - in contrast to the way things have
often gone for standards work - coalesce, inform and focus these efforts
rather than to try to compete with or control them, which we simply
can't hope to do.

brain[sic] 

_______________________________________________
dix mailing list
dix at ietf.org
https://www1.ietf.org/mailman/listinfo/dix