[ID4me Governance] ID4me verified identities framework
sanz at denic.de
Mon Aug 26 08:58:27 UTC 2019
> > - 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
> > - 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