[ID4me Governance] ID4me verified identities framework

Marcos Sanz sanz at denic.de
Mon Aug 26 08:58:27 UTC 2019

Hi Vittorio,

> > - A conceptual one: the paper leaves optional the existence of a data 
> > authority for verified identities (cf "Optionally, a verified identity 
> > also be associated to a data authority"). That would be for example 
> > case if the identity agent itself is performing the identity 
> > However, I think it'd be easier to have it framed this way: for 
> > identities it *always* exists a data authority, it's a decission of 
> > agent if it wants to play that role themselves or delegate it to 
> > else. What do you think?
> It's a matter of definitions, but indeed if an identity is "verified" 
then there must be someone who has verified it, so we could 
> argue that the data authority exists in all cases and sometimes it is 
just collapsed onto the agent (it's actually the symbolism I
> used in the accompanying presentation).

exactly, that's the reason why I'd rather have it framed this way. 

> This could also depend on the implementation in the protocol; for 
example, if we decide that you can tell that an identity is 
> verified by the fact that it includes one or more "data authority" 
claims, then we will require the agent to add itself separately
> into the token as the data authority.

If we follow 
we'll be having so-called "verified claims" that automatically require 
"verification" data (verification process, evidences, trust framework, 
asnd so on). The spec even mandates a claims source to cryptographically 
sign all its assertions. Thus, it just makes sense that the agent also 
does so for the special cases when agent and data authority collapse onto 
one entity.

> > - A technical one, about the entity "certification authority": is that 

> > specifically an X.509 PKI CA as we know it?
> No, actually the idea was more of "certifications" in ISO 9001/14001 
style, i.e. someone validates who you are and your operating 
> procedures and gives you a badge that certifies that you adhere to 
certain organizational standards. I think that the business 
> people that suggested the term had that meaning in mind, but I see why 
it might confuse engineers (especially the web people) so 
> we should look for a different term... accreditation authority? auditing 
entity? something like that.

Ok, yes please, let's change the name. Detlef already made some 
suggestions that follow eIDAS nomenclature, I don't know what could be 
best, but CA is just misleading.

> It's also true that, to make that digital badge automatically verifiable 
by relying parties, and unless someone has better ideas, 
> we have to set up a chain of trust of (X.509?) certificates, so that a 
relying party can verify that the badge is signed by 

That's what I wanted to have out of the governance paper, but since we are 
at it I think X509 wouldn't be the appropriate technology:
I'd rather have a chain of signed JWTs, where the issuer (iss) of a JWT is 
the subject (sub) of the upper link in the chain all the way back to the 
trust anchor, which is a self-signed statement and configured as a 
trust-worthty issuer by members that trust the federation. 
https://openid.net/specs/openid-connect-federation-1_0.html does so for 
RPs and OPs to trust each other by resolving trust from a commont trusted 
3rd party and the same mechanism can be perfectly used for data 


More information about the Governance_wg mailing list