[ID4me Governance] Trust models for identity validation

Vittorio Bertola vittorio.bertola at open-xchange.com
Wed Sep 19 10:51:49 UTC 2018


Hello all,

as you know, ID4me was conceived as a "weak" identity system to facilitate the management and distribution of whatever information the user wants to declare, indipendently from whether it is true or false - just like today's average web registration form.

However, there have been discussions on the idea of providing validated claims through ID4me, where "validated" means that someone will vouch for the fact that those claims actually reflect the true offline values for the owner of the identity.

Before we can work on a technical implementation, however, we have to be sure of how this could work in terms of policy, and especially in terms of trust models: who will be responsible for verifying the user's true identity? Should this be done by the authorities, which could use this as a service differentiator, or by the agents, or even by specialized third parties, or by a mix of parties for different claim types? (e.g. the public property registry can sign claims on properties but not on other things) And how can a relying party decide whether a signed claim is trustable or not?

This is a list of possible different models that I already shared with the Technical WG:
1. the authority takes responsibility for validating claim values (they can then rely on other parties as they want, but they assume responsibility for what they do)
2. the agent takes responsibility for validating claim values (similar to above)
3. claim values can be validated directly by any "validating party" acting as distributed claim supplier, but the ID4me association takes responsibility for vetting validating parties
4. claim values can be validated directly by any "validating party" acting as distributed claim supplier, but each authority takes responsibility for vetting validating parties
5. claim values can be validated directly by any "validating party" acting as distributed claim supplier, but each agent takes responsibility for vetting validating parties
6. no one takes responsibility for vetting validating parties and each relying party decides on its own which validating parties to trust
7. no one takes responsibility for vetting validating parties, but a collective reputation exchange system (blacklists/whitelists or something more refined) is built so that relying parties can use it to decide whether to trust a value

We should possibly build a system that is flexible enough to accommodate multiple models, but first I would like to know if the current "early" players have views or would like to have a role in this field, and which one. So please share your comments!

Thanks
Ciao

--

Vittorio Bertola
Head of Policy & Innovation

Cell: 	+39 348 7015022
Skype: 	in-skype-ox at bertola.eu
Email: 	vittorio.bertola at open-xchange.com mailto:vittorio.bertola at open-xchange.com

Twitter: @openexchange http://twitter.com/openexchange - Facebook: OpenXchange https://www.facebook.com/OpenXchange - Web: www.open-xchange.com http://www.open-xchange.com
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin
Chairman of the Board: Richard Seibt

European Office:
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718
Managing Director: Frank Hoberg

US Office:
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA

Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id4me.org/pipermail/governance_wg/attachments/20180919/f807f726/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1.png
Type: image/png
Size: 65536 bytes
Desc: not available
URL: <http://lists.id4me.org/pipermail/governance_wg/attachments/20180919/f807f726/attachment-0001.png>


More information about the Governance_wg mailing list