Re: [Auth]ISsec Profile Providers (was Re: IDsec meeting)

[Mike Warren]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"John Pugh" <address@hidden> writes:

> Then this will never work for me and my businesses. I refuse to put
> everything in one basket and would imagine others would feel this way as
> well. I only trust a few "providers" 100%, but because some providers
> will provide more services based on what I provide them I will give them
> access to a small portion of info.

I don't think I was sufficiently clear in presenting my idea of
Providers:

The problem:

  I cannot reliably prove to third parties on the Internet that I am who
  I say I am.

Sub-problem:

  It is inconvenient to keep communicating my personal information; I would
  like an easy way to specify to whom I will send what information.


``Third parties'' may be other people, or they could be ``Web
services'' like Hotmail or Yahoo or Netscape.com or eBay or Chapter.ca
which provide services to people (mail, news, auctions,
book-selling). Web services are interested in knowing who their users
are. For some of these services, it is important to know that the
users really are who they say they are (or at least that the person
claiming to live at ``#123 Fake Street'' really does live there). This
is important for Web services which are selling things; they wish to
know that they will receive payment and that they are shipping to a
known address).

It is also important to know that the person claiming a particular
identity is really that person. Note that these identities may very
well be anonymous.

Abstract Solution:

``Identity Providers'' will provide services to allow users to create
and manage person identities. These might be non-anonymous or
anonymous. I would expect most users to have at least two identities
(i.e. an anonymous and non-anonymous one). [I'll leave implementation
details aside as much as possible; whether a anonymous and
non-anonymous identity are included as the same ``Profile'' or not is
irrelevant.]

An Identity Provider should be trusted by the user; ideally, these
identity providers will be serving electronic cash and handling most
monetary transactions for that user; if the user purchases a book at
Chapters.ca with a particular Identity, then Chapters.ca should get
their payment via the Identity Provider and have no need to ever know
the user's credit card information (for example). In this manner, a
user could make anonymous purchases (perhaps some Identity Providers
would even provide a shipping service, where Chapters.ca would ship
the goods to the Identity Provider who in turn would ship them to the
user). Hence, the seller doesn't know to which (real) person they are
selling and the Identity Provider doesn't know what goods the person
bought (necessarily).

The Identity Provider will be trusted by the Web services. In this
way, if the Web service demands a ``real'' name, they can trust that
the Identity Provider has verified this information from its clients
(of course, if the user doesn't wish to actually reveal their real
name to a particular Web service, they shouldn't; this is up to the
user).

This could also be used by other people on the Internet. If I wish to
know someone's real name (perhaps I am thinking of buying something
from them after seeing a posting on USENET), I can ask them to send be
their Identity, which I can then use to get their real name from their
Identity Provider (see below).


More Concrete Solution:

There will exist Identity Providers. These will provide Identity
services to clients (that is, they will allow people to create an
Identity).

Identity Providers will only provide for the creation of Identities
and for decrypting and interpreting Identities to third parties; they
will not control which information in the Identity is given to whom --
that is up to the owner of the Identity.

An Identity will consist of at least: a unique ID (unique to all
Identities from a particular Provider), the Identity Provider which
created the Identity and the public-key of the user. Beyond this, it
can include anything the Identity Provider likes. Realistically, some
standards should be agreed upon for common things like Name, Address,
Credit Card, ...

So.

A User creates an Identity at an Identity Provider. This Identity
includes all the information the User might ever want to verify to
Third Parties in a trust-worthy manner. If the User doesn't care
whether the Third Party believes her, then they can just tell the
Third Party directly and it makes no sense to involve an Identity
Provider. The Identity Provider only exists to verify information so
that a User may reliably communicate it to Third Parties who don't
trust the User 100%.

Once the Identity Provider has created a particular Identity, it gives
the User their Identity Token. This will be an XML file, clear-signed
with the Identity Provider's public-key. It might look like:

<?xml blah blah>
<identity>
  <signed-data>
    <provider name="Toronto Dominion Bank" url="http://www.tdbank.ca";
      verification-service="http://identity.tdbank.ca"; key-id="0xF00B44">

    <user unique-id="unique-id-within-this-Identity-Provider">
      <public-key>
      ASCII-armored public key of the user
      </public-key>
    </user>
    <signature>THE SIGNATURE</signature>
  </signed-data>

  <name>ENCRYPTED</name>
  <address>
    <street>ENCRYPTED</street>
    <city>ENCRYPTED</city>
    <province>ENCRYPTED</province>
    <country>ENCRYPTED</country>
    <phone>ENCRYPTED</phone>
  </address>

<!--
  .etc. there might be more stuff included here, obviously

  perhaps I have purchased a $20 virtual-money-token from TD Bank
  addressed to the same Third Party used in the below examples;
  my Identity Client (also below) could include this token...
- -->

</identity>


Now, each piece of data is encrypted by the Identity Provider. This is
so that the User cannot tamper with it once the Identity Provider has
granted the User and Identity. This is so that once the Identity
Provider has confirmed the user's information, the (untrusted) User
cannot fiddle with it, thus making it completely useless.

Also notice that the required bit of the Identity (the provider,
user-id and user-key) are all signed by the Identity Provider.

Now, when a Third Party asks for a User's Identity, the User's
Identity Client will ask the User which information to reveal (in the
above example, they can choose to reveal or not reveal their Name and
the various bits of the Address).

Lets say the User only chooses to reveal their Name. The Identity
Client then sends only the top bit of the Identity (everything in
<signed-data>) and the <name> block; the <address> block is removed.

(Presumption: the two Identity Clients are communicating through a
secure channel.)

The Third Party's Identity Client receives the information; it
contacts the verification-service specified through a secure
connection (presumption: this connection is not compromised) and asks
for the identity-service's public key, so that the Identity Client may
verify the signatures.

(ALTERNATIVE: the <signed-data> bit could be encrypted instead, and
the Identity Client would then ask the identity-service to decrypt the
data. I don't like this approach, since then the identity-service must
be up at all times for the Identity to be usable).

Presuming the signature comes back as valid (i.e. the User has not
tampered with their Identity), the Third Party's Identity Client then
proceeds to confirm that the User is actually the owner of the
Identity which was sent. It extracts the (now confirmed) public-key of
the User and encrypts a short (random) block of data and sends it to
the User. The User now must decrypt it (using the private key
corresponding to their Identity's public-key, obviously) and send the
data back to the Third Party's Identity Client.

Presuming the User correctly identified herself by sending the correct
decrypted data back, the Third Party's Identity Client can now proceed
to extract the information found in the Identity. It does this by
sending each encrypted piece it is interested in (in this case the
Identity sent to the Third Party only includes <name>) to the
verification-service, which decrypts the data for the Third Party.

ALTERNATIVE: each of the bits of data could just be signed by the
Identity Provider instead, and then the Identity Provider can confirm
the validity of the entire Identity at once. I prefer this approach,
since again it doesn't require that the identity-service is always
available. This would give, for example:

...
  <name signature="SIGNATURE">Mike Warren</name>
...


Using the preferred alternatives, we notice that once a User has an
Identity, it doesn't matter if the Identity Provider goes away as long
as their public-key is still available via some PKI.

(Of course, both alternatives could be implemented...)

Anyway, at this point the Third Party now knows:

. the person claiming to own the Identity is really the person who does

. the person claiming to own the Identity is really called ``Mike
  Warren'' (subject to how much the Third Party trusts that the
  particular Identity Provider has verified this information).

And the User knows:

. the Third Party knows I am really Mike Warren

. the Third Party knows nothing else about me

(NB: if I told my Identity Client to not send my name, either, then
the Third Party would only know that I am the valid owner of an
Identity from ``TD Bank'' with a particular unique-id.)

If I included a $20 virtual-money token (as speculated above), then
the Third Party could attempt to redeem this token at the
identity-provider.  I could verify with the identity-provider that the
Third Party has indeed done so (after verifying who the Third Party is
with the inverse of the above example) and we can now both know that
the $20 transaction has taken place; the identity-provider can verify
this, too, hopefully in a legally-binding manner.

Another service identity-providers could provide is the cryptographic
signing of documents, in order to prove a) that the owner of a
particular Identity signed it and (most importantly) b) that it
occurred at a particular time.

The latter is important (the former can be done easily right now with
GPG); one cannot currently verify *when* they signed a particular
document, since it is easy to change the time on your computer, sign
the document, and change the time back...

If banks (for example) were identity-providers, this cryptographic
signing could potentially be legally-binding, opening up the
possibility of electronic contracts which are legally-binding.


To solve the sub-problem, the Identity Clients must simply be extended
to exchange other, unreliable, information as-needed. They could
provide values to exchange with particular hosts, etc. (For example,
my Identity Client could always tell other Identity Clients that I am
``Meejah Pho-nay'' unless I have included by Name as a reliable value
to send...)

> This is where I see many of flaws of these projects. It appears from
> the information given that the idea of virtual identities is
> limiting what I can do as a consumer of virtual identy information
> and this will severely limit the execution.

Not at all; the owner of a particular Identity will always control
which precise information is revealed to whom. Otherwise, what's the
point?

> The personal directory concept has this. Everyone can implement what
> they want and I can "subscribe" to the value added pieces that I
> wish since everyone will have the choice to have a different
> schema. The base schema will be the same across the board as it is
> required to authenticate. But, that's the only control exerted. This
> allows me to vary my trust and not put all my eggs in the same
> basket(s). Then I can build services on top of this consuming the
> different attributes I need with a specific provider.

I don't understand what you're getting at.

> See...the user AND the provider/web service needs the ability to
> consume/provide value-add.

Perhaps I wasn't clear; I was using ``web services'' as an example;
anyone may be the ``consumer'' of information out of a particular
Identity (as I hope my above example makes clear).

> I may be missing the point, but I only trust a handful of
> people/business and that trust is 100% for a very select few.

Yes, this is exactly the point: you should only trust perhaps one
``Identity Provider'' with your credit card information. Currently,
you have to trust anyone you want to buy something from with this
information.

I would expect that a particular person would only have one Identity
Provider (like most people deal primarily with one bank).

Anyway, I hope this makes my vision more clear,

- -- 
address@hidden
<URL:http://www.mike-warren.com>
GPG: 0x579911BD :: 87F2 4D98 BDB0 0E90 EE2A  0CF9 1087 0884 5799 11BD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8B/85EIcIhFeZEb0RAu4oAJ9pcegE1VGhYOI6TrzNe5VX9cvpuwCgubJS
kE2O3YZQH3tbEYMkDGDXwfk=
=kdoS
-----END PGP SIGNATURE-----