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

["Hallam-Baker, Phillip" <pbaker at verisign.com>]

I agree at some level, but again, you are assuming that we are dealling
with the most sophisticated 50% of internet users, not the least
sophisticated ones.

Back in 1995 I proposed a scheme that would allow people to
automatically fill in forms by establishing systems common tag values
for form fields. Got laughed at. Four years later the same blighters who
had laughed then tried to do the same thing but it was too late by then
to do it well.


I think that we have to break down the problem into parts. First there
is the question of the identifier. I am the only person on the Internet
who is allowed to call themselves pbaker at verisign.com. We can argue that
this is subject to employment status but the basic principle still
stands, if I want a name that is entirely mine I need to get my own
domain name.

Once we have an infrastructure that allows me to securely establish that
I am the genuine pbaker at verisign.com to any other party on the net and
without revealing to them information that allows them to go and
impersonate me then we can go on to do the types of thing you talk
about. But first we have to provide the infrastructure that allows me
and only me to lay claim to my identifier.


Bridging the gap from identifier to identity is probably going to
involve policy decisions that are mediated by my identifier registry. I
am not sure we even need to introduce standards there, SAML allows that
information to be transported already.


> -----Original Message-----
> From: THOMAS, BRIAN M (SBCSI) [mailto:bt0008 at att.com] 
> Sent: Thursday, January 05, 2006 8:32 AM
> To: Hallam-Baker, Phillip; IETF DIX list
> Subject: FW: [dix] thoughts on "identity" and IETF
> 
> 
> 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