[ID4me Governance] [Technical_wg] ID4me verified identities framework

Matthias Pfeifer | dotBERLIN GmbH & Co. KG pfeifer at dot.berlin
Fri Aug 23 13:18:24 UTC 2019


Dear List,

and first many thanks to Vittorio :)
 
> 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?

[>] For my understanding: With this scenario it *might* be possible to think about a setup wheras an agent and authority is as it is the orign of trusted identity with no need for a data authority. For e.g. this model might be intersting for an LOA which wants to run some of the parts by themselve for some benefits within the ID4me framework (rather than an OIC setup).


Best, Matthias


> - 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
> 
> _______________________________________________
> Technical_wg mailing list
> Technical_wg at lists.id4me.org
> https://lists.id4me.org/cgi-bin/mailman/listinfo/technical_wg


More information about the Governance_wg mailing list