[ID4me Governance] ID4me verified identities framework

Marcos Sanz sanz at denic.de
Fri Aug 23 13:09:04 UTC 2019


Hi Vittorio,

> as promised, we have been working on a mechanism for ID4me "verified 
identities" - i.e. identities that provide some level of 
> assurance over the truthfulness of their claims. Several participants 
see this as an important use case and we are committed to 
> adding support for it quickly. We want to agree on a framework as soon 
as possible so that we can work on the missing technical 
> and organizational parts (if any). 

thank you very much for the paper. Three comments:

- A conceptual one: the paper leaves optional the existence of a data 
authority for verified identities (cf "Optionally, a verified identity can 
also be associated to a data authority"). That would be for example the 
case if the identity agent itself is performing the identity verification. 
However, I think it'd be easier to have it framed this way: for verified 
identities it *always* exists a data authority, it's a decission of the 
agent if it wants to play that role themselves or delegate it to someone 
else. What do you think?

- A technical one, about the entity "certification authority": is that 
specifically an X.509 PKI CA as we know it? It reads/feels like that, but 
I think it would be better to leave out of the paper the concrete 
technology being used (beyond requiring it to be cryptographically 
secure). For instance, the OpenID Federation specification (draft in 
progress, https://openid.net/specs/openid-connect-federation-1_0.html) 
implements their whole Trust Anchor/Trust Chain model only with signed 
JWTs. As a matter of fact, X509 certificates hardly play any "content 
role" in the whole OpenID Connect: they are explicitly excluded from the 
federations spec as a source of trust ("the trust chain does not at all 
rely on TLS [RFC8446] in order to establish trust.") and, though OpenID 
Core requires ubiquitous HTTPS and TLS certificate checks ("TLS server 
certificate check MUST be performed"), its aim is only securing the 
communication channel, since the JWT objects within the channel can still 
be signed and/or encrypted with other purposes.

- A nit: If I get the meaning right, in page 5 it says "the relying party 
will then refer to the data authority" but it should say "the relying 
party will then be referred to the data authority". Is that correct?

Best regards and a nice weekend to everyone
Marcos

> 
> I am attaching the general document that describes the framework, in a 
draft that has been initially worked out among the working 
> group chairs; we would like to discuss it with the membership and 
release a final version by the ID4me Summit in October at the 
> latest. I am also attaching a presentation that might be useful to 
understand the concepts and the different scenarios that have 
> been considered. 
> 
> As the concepts are not totally immediate, I am happy to organize a call 
next week to go through them, take questions and get 
> feedback, if anyone wants - let me know. You are also welcome to provide 
feedback here on the list. Thank you in advance for any 
> contributions. 
> 
> Ciao, 
> -- 
> Vittorio Bertola 
> Head of Policy & Innovation 

> 
> Cell:
> 
> +39 348 7015022
> 
> Direct Chat:
> 
> vittorio.bertola
> 
> Email:
> 
> vittorio.bertola at open-xchange.com
> 
> Twitter: @openexchange - Facebook: OpenXchange - Web: 
www.open-xchange.com
> 
> [image removed] 
> 
> Open-Xchange AG, Hohenzollernring 72, 50672 Cologne, District Court 
Cologne HRB 95366
> 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.
> 
> [attachment "ID4me Verified Identities - Draft 3.pdf" deleted by Marcos 
Sanz/Denic] [attachment "ID4me trust model 
> introduction.pdf" deleted by Marcos Sanz/Denic] 
_______________________________________________
> Governance_wg mailing list
> Governance_wg at lists.id4me.org
> https://lists.id4me.org/cgi-bin/mailman/listinfo/governance_wg



More information about the Governance_wg mailing list