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

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 9 Nov 2005 15:05:14 -0800 (PST)

I have been somewhat involved in recent discussions regarding "identity" 
(see http://www.identitygang.org/ and a zillion other blogs and links), as 
well as a long-time IETF participant, so let me toss out a brief personal 
view of what's going on here in hopes it may provide context useful for 
some folks.

Let me say up front that I don't necessarily agree with all the positions 
I describe below, but am trying to express what many people are saying and 
thinking.

Many protocols developed in the IETF have served the needs of what Dick 
Hardt calls "Identity 1.0", which might be characterized less flamboyantly 
as "enterprise identity management".  This term includes several rather 
different technologies and processes, all in support of the ability for 
the owners of services to control who does what with their computing 
resources.  I use the word "enterprise" above intentionally, to reflect 
the fact that traditionally the parties with interest and ability to 
control access to resources have been organizations, usually large ones.

So, for example, the domain of use of the IETF's LDAP protocol is large 
directories containing entries for many users, operated by IT staff in 
organizations that have an interest in the users whose info is in those 
entries, and the applications that use those directories.  The domain of 
use of the IETF's Kerberos protocol is similarly organizations with an 
interest in secure authentication to a set of apps relying on an 
organizational KDC.  Similar broad-brush characterizations could be made 
of PKIX, TLS, SASL, features like HTTP Basic/Digest authentication, 
probably other protocols and features.

Note that the scope of "identity" here includes several things.  One is 
maintenance of information about a person (or other entity), including not 
just userid and password but potentially lots of other information 
relevant to authorization, contact, perhaps other purposes.  Another is 
authentication, ie how a service knows "the identity" of a client. 
Another is exchange of identity information between parties, both at 
authentication time and at other times.

Out in the world most people's experience of the Internet is of course the 
Web, and most people's experience of "Identity 1.0" has been via account 
setup and login to a vast array of web-based services managed by 
organizations large (mostly) and small.  There have been some non-IETF 
standard/spec activities that attempt to address the widely-observed 
usability problem of people having too damn many usernames/passwords to 
remember, as well as security problems based on that stuff.  Perhaps the 
main one is the OASIS-published SAML standard, which specifies how to do 
web sign-on and attribute exchange.  A somewhat similar activity is 
WS-Federation, part of the WS-* spec set.  These have been called 
"Identity 1.5" because they permit some organizations to rely on other 
organizations' identity management services, but the use cases driving the 
designs are still organization-oriented.

So is there something missing in the above stuff, some new requirements 
requiring new stuff, ie "Identity 2.0"?  I think the people who say there 
is are motivated by the huge number of new things that have happened on 
the web in the last few years.  The center of this is the blogging 
phenomenon.  Maybe 20 million people are now blogging.  They're doing 
other things like putting lots of photos online at Flickr, keeping their 
bookmarks on del.icio.us, tracking tags on technorati, and zillions of 
other examples.  They are composing these services in myriad ways to 
create new services.  In sociological terms they are creating online 
identities for themselves that they feel much more attachment to than 
their organizational account, even their "my.foo.com" page at one of the 
traditional portal sites.  In Identity 1.0 terms they are all becoming, or 
have an interest in becoming, both service providers and identity 
providers, that is, they have an interest in protecting their resources 
(in the canonical case of reducing blog spam), and in leveraging their 
personal info to their millions of peers.

So now in addition to the tens or hundreds of thousands of institutions 
with identity interest, there are tens of millions of individuals.  Many 
people are trying to figure out what they need and respond to it.  The 
SXIP technology is one among those, others are OpenID, LID, Passel, and no 
doubt many others.  For the most part these approaches reject traditional 
identity management protocols and systems; whether they should or should 
not is one of the big questions.  A key point is that the individual 
interest in identity is much more about expression, ie ease of sharing and 
discovery, than it is in control (ie, fancy security).  Another key point 
is individual control, the same sort of control people feel over their 
personal domain name and its site, or their blog.  Even people who aren't 
radically anti-corporate like to feel in charge of their own stuff.

That's all I have time for now ...

  - RL "Bob"

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Nov 2005 09:55:02 -0700

Hi Bob, thanks for the context.

RL 'Bob' Morgan wrote:

> In sociological terms they are creating 
> online identities for themselves that they feel much more attachment to 
> than their organizational account, even their "my.foo.com" page at one 
> of the traditional portal sites.  In Identity 1.0 terms they are all 
> becoming, or have an interest in becoming, both service providers and 
> identity providers, that is, they have an interest in protecting their 
> resources (in the canonical case of reducing blog spam), and in 
> leveraging their personal info to their millions of peers.

People are increasingly "amphibious" -- they've got one foot in the old 
world of real-life identity and one foot in the new world of online 
identity. As more identity moves online, we need to find ways to 
express, share, manage, and control it. SAML uses the term "assertion" 
and I think we're talking about the same kind of idea in a personal 
context -- who gets to make assertions about who I am online? Perhaps 
part of the frustration with existing identity systems is that they do 
not put the individual in control (no fault of the existing identity 
systems, since as you point out individuals didn't have online 
identities back then).

> SXIP technology is one among those, others are OpenID, LID, Passel, and 
> no doubt many others.  For the most part these approaches reject 
> traditional identity management protocols and systems; whether they 
> should or should not is one of the big questions.  

Well, probably much could be done with the existing public key 
infrastructure, but I note with sadness that very few people even on 
IETF lists digitally sign their emails. If even the hardcore bit-heads 
aren't using PKI, why should we expect anyone else to?

> A key point is that 
> the individual interest in identity is much more about expression, ie 
> ease of sharing and discovery, than it is in control (ie, fancy 
> security).  Another key point is individual control, the same sort of 
> control people feel over their personal domain name and its site, or 
> their blog.  Even people who aren't radically anti-corporate like to 
> feel in charge of their own stuff.

Yes, expressing your identity online, sharing it with others, managing 
it, and controlling its canonical expressions are important parts of 
what's happening. It seems to me that we need to really think about what 
each of these entails. For example:

Part of expressing online identity may involve formulating a common 
language or flexible structure for capturing such assertions (which is 
already happening from the bottom up through Flickr, FOAF, tagging, and 
the like).

Part of sharing online identity may involve figuring out how one can 
assert ownership over the information one shares (what some are calling 
"identity rights agreements", kind of a Creative Commons in reverse).

Part of managing online identity may involve improving on the existing, 
informal process of registering with websites, known as "email based 
identification and authentication" (EBIA).

Part of controlling online identity may involve explicitly tying 
assertions to individuals (PKI again?) and treating individuals as the 
canonical source of information about themselves (without implying that 
others cannot make assertions about individuals, naturally).

These are all interesting topics. It's not clear to me what the IETF's 
role is here. Do we have engineering tasks to complete yet? (If so, 
which aspects are folks proposing to work on?) Are these more like 
research topics for the IRTF? Does identity work even belong in the 
IETF? I have opinions, but right now I'm just asking the questions.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 12 Nov 2005 13:07:55 -0800

RL 'Bob' Morgan wrote:
>
> So is there something missing in the above stuff, some new
> requirements requiring new stuff, ie "Identity 2.0"?  I think the
> people who say there is are motivated by the huge number of new things
> that have happened on the web in the last few years.  The center of
> this is the blogging phenomenon.  Maybe 20 million people are now
> blogging.  They're doing other things like putting lots of photos
> online at Flickr, keeping their bookmarks on del.icio.us, tracking
> tags on technorati, and zillions of other examples.  They are
> composing these services in myriad ways to create new services.  In
> sociological terms they are creating online identities for themselves
> that they feel much more attachment to than their organizational
> account, even their "my.foo.com" page at one of the traditional portal
> sites.  In Identity 1.0 terms they are all becoming, or have an
> interest in becoming, both service providers and identity providers,
> that is, they have an interest in protecting their resources (in the
> canonical case of reducing blog spam), and in leveraging their
> So now in addition to the tens or hundreds of thousands of
> institutions with identity interest, there are tens of millions of
> individuals.  Many people are trying to figure out what they need and
> respond to it.  The SXIP technology is one among those, others are
> OpenID, LID, Passel, and no doubt many others.  For the most part
> these approaches reject traditional identity management protocols and
> systems; whether they should or should not is one of the big
> questions.  A key point is that the individual interest in identity is
> much more about expression, ie ease of sharing and discovery, than it
> is in control (ie, fancy security).  Another key point is individual
> control, the same sort of control people feel over their personal
> domain name and its site, or their blog.  Even people who aren't
Kerberos is best known as an authentication system used by large
organizations.  It is thought that setting up and managing a Kerberos
realm requires too much infrastructure and in particular too much
administration for use by the masses.   However, this is not necessarily
the case.   There is another model that has been discussed within the
Kerberos development community but has not received much attention
elsewhere.   Instead of maintaining a very small number of highly
trusted realms with thousands to hundreds of thousands of principals,
what if it were possible for every computer that maintains its own set
of local user accounts to be a realm?  In this world service providers
of e-mail, blogs, photo albums, etc. would all establish Kerberos
realms, not to issue client principals but only to issue service
principals for the service instances running on their clusters of
computers.   The client principals would be managed by the users in
their own realms.

The magic that enables the client principal [email-masked] to be accepted
by blog/[email-masked] is Kerberos cross-realm
authentication.  The client application connecting to the blog service
on some.machine would query the MY.PC KDC for a cross-realm ticket for
BLOG.PROVIDER.  After receiving such a ticket the client application
would contact a BLOG.PROVIDER KDC to obtain the
blog/[email-masked] service ticket that would in turn be
used to authenticate [email-masked] to the blog service.

If you have been paying close attention you will be asking yourself,
"how can the MY.PC KDC issue a cross-realm ticket granting ticket for
the BLOG.PROVIDER realm?   The MY.PC realm administrator did not
exchange a key with the BLOG.PROVIDER realm administrator."  The answer
to this problem is a proposal put for almost a decade ago entitled
"Public Key Cryptography for Cross-Realm Authentication in Kerberos".  A
copy of the expired draft can be found in the Dec 1998 IETF
proceedings. 
http://www3.ietf.org/proceedings/98dec/I-D/draft-ietf-cat-kerberos-pk-cross-05.txt
By using public key cryptography (with or without a PKI) to perform the
key exchange, it is possible to remove the need for the manual exchange
of keys by the administrator.   Instead, "leap of faith" methods can be
used to allow an individual to register their principal name with a
service and validate the authenticating realm in much the same way that
receipt of an e-mail and subsequent access to a URL is used.  

One of the nice benefits of using Kerberos is that it is a proven
technology that has pre-existing wide spread deployment.   Every major
OS has Kerberos support already available for it.   The Kerberos ticket
format can also be used to exchange additional identity or authorization
data.  This data can be inserted by the realm issuing the ticket
granting ticket or the realm issuing the service ticket.   I grant that
not all of the required functionality is available in the Kerberos
support shipped in today's systems.  However, adding the support as an
incremental change to Kerberos would be no harder than adding support
for an entirely new infrastructure that does not exist in any form.

I look forward to answering any questions you might have.

Jeffrey Altman

---

From: "D'Andrew \"Dave\" Thompson" <[email-masked]>
Date: Mon, 14 Nov 2005 18:15:10 -0800

I wonder if rather than simply creating yet another protocol for
security authentication/authorization we can't begin defining other
aspects of identity as it has evolved.

Perhaps we can begin establishing a manner to negotiate differing
levels of trust need (as I am calling it) and probability thresholds.
For example, it isn't always necessary that an identity must provide
date of birth, social security number, etc. Rather, if the mitigating
risks in a given action are minimal, than the level of trust need is
lessened. Consequently, a lower probability threshold can be
established in determining the probability that an identity is indeed
who they say they are.

For example, if a service is providing authentication/authorization
for a online newspaper subscription, the risk of any identity gaining
access to their service is not very high, so perhaps a given
definition describing their risk level, trust need, and probability
threshold could allow them to quickly authenticate based upon that
given context. Whereas a bank's risk level will be much higher
demanding a greater trust need, and hence a greater probability
threshold. They could have a standard way of describing this context
so that a user could provide the required level of identity
verification.

Aside from the benefits of a standard way to discuss contextual
identity, this would certainly substantiate a more precise legal
precedence for fraud prosecution based upon risk levels, allowing for
businesses to mitigate their online risk appropriately and on a
standard level.

Just some thoughts...

Thanks for listening.  -Dave

--
~~~~~~~~~~~~~~~~~~~
D'Andrew "Dave" Thompson
http://dathompson.blogspot.com

---

From: John Merrells <[email-masked]>
Date: Tue, 15 Nov 2005 10:34:44 -0800

On 10-Nov-05, at 8:55 AM, Peter Saint-Andre wrote:

> Perhaps part of the frustration with existing identity systems is  
> that they do not put the individual in control (no fault of the  
> existing identity systems, since as you point out individuals  
> didn't have online identities back then).

I think this is a fundamental property of a successful internet
scale digital identity architecture, and part of the reason why
existing solutions have not achieved mass adoption. (Kim's
first law basically...)

> These are all interesting topics. It's not clear to me what the  
> IETF's role is here. Do we have engineering tasks to complete yet?  
> (If so, which aspects are folks proposing to work on?) Are these  
> more like research topics for the IRTF? Does identity work even  
> belong in the IETF? I have opinions, but right now I'm just asking  
> the questions.

All good questions Peter.

Role? The IETF's role is to provide an open venue and a
process within which disparate interests can come together
  to agree on a 'solution' to this problem.  Step one is to
define the problem. Bob and yourself have come up with
good requirements statements and use cases. I'll feed that
into the proposed charter, which is on my list of this to do
asap.

Research? No. Code and been written and deployed...
SXIP, LID, OpenID, Passel... We need a standard and
we need interoperable implementations.

Belong in the IETF? For sure. This is an internet wide
problem and it's an end-to-end problem. Our 'customers'
are individuals with an an online presence who are
currently hampered by a lack of a ubiquitous and
secure means to perform identity transactions.

John

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Nov 2005 20:23:32 +0100

On Nov 15 2005, at 19:34 Uhr, John Merrells wrote:

> Step one is to
> define the problem.

Quite obviously so.

> [...] I'll feed that
> into the proposed charter,

One way to arrive at a sufficiently focused problem definition is to  
do this in the WG chartering process.

Given the complexity of the undertaking, success is more likely when  
the group is initially chartered just to do a problem statement.
Once that exists, it can then be rechartered to do elements of the  
required standardization.

(Note that the IETF does not like "requirements" documents, as these  
are often rigged by proponents of specific solutions to favor these  
over others.
We do problem statements, or -- if these are still to ambiguous --  
refine these into statements of objectives.)

The important thing is that there is no reason to wait for the BOF in  
Dallas -- a problem statement could evolve as (one or more)  
individual submissions, so things are already well-progressed  by  
Dallas.  (Individual submissions can be discussed on the list, so we  
already have generated something like a WG consensus even before the  
WG formally exists.)  A good (set of) individual submission(s) will  
also lend focus to the BOF itself and increase the likelihood of  
actually having a WG afterwards.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Nov 2005 20:34:50 +0100

On Nov 15 2005, at 20:23 Uhr, Carsten Bormann wrote:

> individual submissions

Still suffering from Vancouver jet lag.
Of course, I meant individual internet-drafts, not yet submitting  
anything to anyone.

Gruesse, Carsten

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 15 Nov 2005 15:03:02 -0800

--On 15. november 2005 20:23 +0100 Carsten Bormann <[email-masked]> wrote:

> (Note that the IETF does not like "requirements" documents, as these  are
> often rigged by proponents of specific solutions to favor these  over
> others.

note:
the IETF currently is frequently asking for "requirements" documents to be 
written. Many people don't like them, but some people do.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Nov 2005 14:43:49 -0700

> into the proposed charter, which is on my list of this to do

Cool beans, I'm looking forward to it. :-)

Peter

---

From: [email-masked]
Date: Wed, 16 Nov 2005 15:34:24 -0800

I'm sorry, I don't think I missed any messages in this thread but seem to 
have missed where I might go to see these requirements statements and use 
cases... can someone point me in the right direction? THANKS!!

Andy Dale
ooTao

Phone: 877-213-7935
Fax: 877-213-7935

i-name: =Andy.Dale
http://public.xdi.org/=andy.dale

***************************************************************************
If you don't have your iName yet use this link:

   http://2idi.com/registrar/index.html?referral_code=ootao

***************************************************************************

Peter Saint-Andre <[email-masked]> 
Sent by: [email-masked]
11/16/2005 01:43 PM

To
John Merrells <[email-masked]>
cc
[email-masked]
Subject
Re: [dix] thoughts on "identity" and IETF

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Nov 2005 17:11:29 -0700

[email-masked] wrote:

> I'm sorry, I don't think I missed any messages in this thread but seem 
> to have missed where I might go to see these requirements statements and 
> use cases... can someone point me in the right direction? THANKS!!

These may (or may not) be helpful:

http://www1.ietf.org/mail-archive/web/dix/current/msg00007.html
http://www1.ietf.org/mail-archive/web/dix/current/msg00008.html

Not sure I would call those requirements statements or use cases, 
though, more like preliminary maps of the territory.

> i-name: =Andy.Dale

Oh, and I'm =stpeter too... ;-)

Peter

---

From: Hallett German <[email-masked]>
Date: Thu, 17 Nov 2005 04:09:37 -0800 (PST)

As this effort goes on, it may be helpful to look at
leveraging Common Criteria since it is fairly complete
when dealing with security requirements.
Hal German

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 17 Nov 2005 07:56:54 -0600

>when dealing with security requirements.

Leveraging in which ways ? I don't think that the CC is at all complete
when dealing with security requirements, it deals well with assurance
requirements but leaves other requirement on the floor

Anthony Nadalin

---

From: Hallett German <[email-masked]>
Date: Thu, 17 Nov 2005 09:27:40 -0800 (PST)

Anthony:
   I will respond to this note only  and do not wish
to start a thread on this topic.
   I offer Common Criteria as something that may help,
and if it doesn't help in creating requirements
thats's ok as well.
    Yes, it has its own vocabularly that takes some
learning. But as a starting point (IMHO), it is
helpful in creating a framework of inter-related
requirements.
I agree that there are other aspects that it covers
but not in the same level of detail.
In any event, I too look forward to seeing the
requirements draft
Hal German.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 17 Nov 2005 19:04:12 -0800

in the interest of sanity.... when someone uses a term like "Common 
Criteria", would it be possible to add a reference - full title, publisher, 
version and possibly an URL?

I know that people who live and breathe CC have trouble imagining that 
anyone could be ignorant of them.... but it's been 5 years since I last had 
to think about them, and I have no idea what the current version or URL 
is....

                  Harald

---

From: "Haripriya S" <[email-masked]>
Date: Mon, 28 Nov 2005 01:53:06 -0700

Hi all,

I am new to this list but have done some work with identity. What I
understand is that the working group will come up with requirements
initially and later an architecture and possible set of standards for
intenet-scale identity systems to support the 'Web 2.0' requirements
that Bob talked about. I feel It would also be good to define capability
requirements for the digital identity systems supported by this
architecture, where products can comply with one or more levels of
requirements thus giving a slate of products with various capabilities
to suit different domains and classes of use.

As an example, I can think of capabilities of identities like -
anti-spamming, anti-theft, easy-to-create, one-time-use, federatable,
easy-to-share, distributed-creation, distributed-authentication etc. An
online bank could be interested in identity systems that support say,
anti-theft properties. An online community on the other hand may be
interested in ease-of-creation and ease-of-sharing. Probably this is a
stupid example, but what I am trying to say is that the architecture to
be developed should cater to various classes of usage, and should be
able to support various identity designs and products that cater to each
of these categories. They should also have a basic architecture with
minimal capabilities, which will let them interoperate at a minimal
level even if they belong to different capability levels.

My two cents!

Thanks,
Haripriya
 
>>> "RL 'Bob' Morgan" <[email-masked]> 11/10/05 4:35 am >>> 

<snip>

with identity interest, there are tens of millions of individuals. 
Many 
people are trying to figure out what they need and respond to it.  The

SXIP technology is one among those, others are OpenID, LID, Passel, and
no 
doubt many others.  For the most part these approaches reject
traditional 
identity management protocols and systems; whether they should or
should 
not is one of the big questions.  A key point is that the individual 
interest in identity is much more about expression, ie ease of sharing
and 
discovery, than it is in control (ie, fancy security).  Another key
point 
is individual control, the same sort of control people feel over their

personal domain name and its site, or their blog.  Even people who
aren't 
radically anti- corporate like to feel in charge of their own stuff.

  -  RL "Bob"

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Nov 2005 15:28:35 +0100

On Nov 28 2005, at 09:53 Uhr, Haripriya S wrote:

> online bank

Are these even in scope?

I was hoping we were focusing on the things that cannot yet be done  
with Liberty-Alliance/SAML-style identities.

Gruesse, Carsten

---

From: Doug Royer <[email-masked]>
Date: Mon, 28 Nov 2005 18:46:54 -0700

Before there can be a new solution I think we need to list what is wrong
with current solutions. I would be interested in reading about other
needs even when slightly out of scope to this WG so that we can
find the overlap that will be useful.

I did some consulting and coding for the mortgage industry here in the
USA (mismo.org e-signing and document control). They use XML and
digitally signed documents such as deeds, titles, and load documents.

Some of the issues below are more than identity, however they describe
many issues that my customers have seen over the last few years where
their core issue was identity, authorization, and chain of authority.

The problems they ran into are:

	They had to be their own CA
	  They had to issue the ID's and not use a commercial
	  company as they needed to do more checking than an email
	  address and credit card.

	Role vs Identity vs Authority
	  A Person starts off as a secretary and signs some documents.

	  Later they move up to load officer and can now sign loans.
	  Same ID, different role.

	  While their manager is out of town, they temporarily have
	  the authority to sign other documents.

	  With current solutions, they simply get a new digital
	  signature. The fact that it is the same person may
	  get lost. No standard way to track ID information
	  by asking a CA.

	Roles need a range of time valid in the signature.
	  In the example above, the person is only a temporary
	  manager. An expire date may not be known when
	  the signature is issued. (How long will my
	  manager be in the hospital?).

	Roles need some kind of non-CA tree-of-authority.
           John said that Mary can sign this document. This
	  implies a work flow protocol be in place to track
	  the chain of authority as it relates to the role
	  and ID.

	  I could work for an ISP. While working I am still
	  ID == DOUG. While not working I am still ID == DOUG.
  	  However my ROLE went from SUPPORT@ISP,com to DOUG.
	  And supervisor@ISP said that ID == DOUG can use
	  [email-masked], co-signed by CA-ISP.com

	Long term tracking (think 20 years or more) of digital IDs.
	  A protocol to store and fetch IDs and CA information over
	  long times is needed. As in who signed this deed 15 years
	  ago, and tell me about them.

	  Who authorized John to sign this document 15 years ago?

	  With email certs [email-masked] may not be the
	  same person that it was 1 year ago.

	No registry for 'user defined' data in signatures.
	  They needed notary ID and state into a digital
	  signature. Some 'user defined fields' would be nice
	  in the cert. And some registry for knowing how to
	  use them.

	  Maybe a user defined field protocol to the CA to
	  get text explanations of the user defined fields.

Many say the revocation checking and process is what does not scale.
For my customers we used a unique suffix to all the signatures
revocation URLs so that it only looked like it was in one big file.
(server.com/revoke-some-id). A DAV like server broke it down
to a database.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards