Hi John,
Thanks for your comments! I have added some clarifications below.
In this information exchange architecture, the Content Provider "needs"
to know the URI of the agency where I store my data to conduct a
transaction? That meta-data (who my content provider is) is my private
business! Unless I want to tell the content provider where my data is, I
should not have to, but the IDsec transaction architecture forces me
Right. But one has to make a decision here: either transfer your profile
with your request or pass a URI where it can be fetched. We chose for
the latter because it enables users to delegate the task of profile
provisioning which we think is an advantage. However it also
incorporates the first: you can still be your own profile provider.
And yes, you tell the Content Provider where your data is, but in the
case of running your own profile provider, this boils down to your own
IP address, which he knows anyway because you visit his site...
too! Additionally, the Profile Provider knows who I am interacting with
by virtue of the IP address of the requestor. My profile provider should
not know whether I'm accessing the Wall Street Journal anymore than he
should know I'm accessing a pay-per-view porn camsite. That information
is my private business regardless of who I am, or what I am accessing.
Once my Content Provider knows who my Profile Provider is, they can
Right. You have to trust your Profile Provider; if you don't, you have to
be your own Profile Provider. A scenario in which a Profile Provider
merely acts as a remote storage provider (by means of encrypted profiles)
is too clumsy in my opinion. In that case the Storage Provider does not
give you added value because you would have to do the tasks of
profile provisioning yourself (which by the way is covered in the
be-your-own-profile-provider scenario); if you don't want to do it
yourself you get the problem of distributing keys to Content Providers
to decrypt profile (parts). This would require secure connections
between End-Users and Content Providers which is something that we
didn't want to enforce.
IDsec *requires* that I trust my profile provider, now and in the future
and for all time. I shouldn't have to. IDsec requires me to. IDsec may
Yes, that's true but necessary in my opinion. Again:
if you don't trust anyone to be your Profile Provider, the
solution is to be your own Profile Provider (and still use IDsec :-)).
let me distribute only the personal data I choose, but (and this is a
sticky but) IDsec gives me no control over what metadata I distribute.
I don't think that this metadata is sensitive or that it is much:
in fact it's only a URI. I really think that security should not consist
of hiding a URI: it won't work anyway in the long run, the solution is to
protect *access* to the URI.
Hans, I'm still working on the schema extraction of the Mozilla wallet.
Still interested?
Yes, I just chose some (fairly random) attributes for standardization
myself.
But I really need a more exhaustive, real-world set.
Thanks again,
Hans.
_______________________________________________
Auth mailing list
address@hidden
http://subscribe.dotgnu.org/mailman/listinfo/auth