OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] Agenda for XDI TC Call Monday 3/22 5PM Pacific


Jean Luc -

Netimo looks interesting - thanks for the introduction and overview.
I'm glad to see others looking closely at the need for distributed PKIs
and finer grained control over the sharing of profile information.

The key-exchange mechanism you present sounds similar to that presented
in _Public-key Support for Collaborative Groups_ (Steve Dohrmann and
Carl Ellison, <http://www.cs.dartmouth.edu/~pki02/Dohrmann/>).  Have you
looked at SPKI/SDSI?  I think it's very useful to this kind of work.
Here are some links:
http://world.std.com/~cme/html/spki.html
http://theory.lcs.mit.edu/~cis/sdsi.html

I'm very curious about XPIML - have you any further documentation on it?
What we in the Identity Commons are planning/expecting is a continuously
evolving link contract language that starts with a simple implementation
of Authorization, Version, DataSet, CachingAllowed and ForwardGroup
constructs (names subject to change) and grows as the community demands.
(We're taking a grassroots approach ;-)

Data sets will be accessed via an XRI that contains a link contract.
The resolution process of this link contract first checks (nominally)
Identity Commons membership standing, as Identity Commons members who
operate conformant XRI resolvers will have signed a legally binding
agreement that they will abide by the terms of any accepted link
contract.  Only after valid membership standing has been determined -
and the contract has been agreed to and securely noted by the contract
resolver/broker via a signed and dated certificate including a hash of
the contract - will any of the data protected by the contract be
available to the requesting party.  It is our feeling that though
members could agree to the contract and then operate contrary to its
specifications, the possibility - should they be discovered - of losing
their membership or at least some level of reputation for such aberrant
behavior would be too great.

I'm not sure what your business model is, but ours is pretty open.
(Disclaimer: I'm a tech guy - not the biz guy.)  Perhaps we can find
places that our technology development can support each other?

Best,
Fen


jlschellens@netmino.org writes:

> Hello Drummond,
>
> I'm not yet sure I'll be able to attend this meeting. For me it'll 2
> am and I've to convince my wife for such an early wake-up! 
>
> Before I will join the use cases works, I would like to summarize the
> 3 steps of the negotiation process we defined in Netmino for the
> exchange of personal data. 
>
> 1. In the first step, the two persons (individual or organisation)
> candidates for a relationship will exchange their public keys.
> -	In a "face to face", they will use Keymino, the software
> we are developing for PDAs and GSMs. Keymino allows the exchange
> (through IrDA, Bluetooth or MMS - SMS is to small to carry a Public
> Key) of basic data about a person: his first name and name, picture,
> e-mail address and public key. The data will be different following
> the type of relationship, e.g. for anonymous relationship, the first
> name and name are not disclosed and the e-mail address will be like
> BE1234567.56@netmino.com; for a business relationship, the address
> will be the firstname.name@company.com with maybe another public
> key
> -	In the other cases, e.g. through the Web, the exchange of the
> basic data will be done by e-mails through a Netmino server and
> require an authentication process (where indeed SAML can be used). 
>
> 2. In the second step, the two persons will exchange by encrypted
> (with the previously exchanged public keys) e-mails their "Privacy
> & Identity Contract" (a link contract) using XPIML (eXtensible
> Privacy & Identity Markup Language, previously XPrML) to confirm the
> type of relationship they want to have (anomino, pseudomino, family,
> friend, business, employee, prospect, customer, administrated) and
> the authorised uses of the to be exchanged personal data in relation
> to their privacy preferences (e.g. automatic update, copy & back-up
> but no print or forward to third parties -- I hate the vCard forward
> feature e.g. in Outlook, it's totally against my privacy
> principle!).
> The PICs will be signed using the private keys of the two persons.
> This step is fundamental for a trusted relationship between the
> persons and can be seen as the acceptation you're asked to give
> when you install software. 
>
> 3. In the third step and only if the two persons have exchanged by
> encrypted e-mails their signed PICs, the personal data will be
> exchanged again by encrypted e-mails, the data being (pre-) formatted
> in "virtual cards" again following the type of relationship
> between the two persons (from anomino to full disclosure e.g. for your
> next employer). 
>
> I would like to know if you share this very definite approach and
> would appreciate all your reactions and comments. 
>
> Regards,
>
> Jean-Luc
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]