[Openid-specs-ab] OpenID Connect for Identity Proofing (Proposal)
sanz at denic.de
Wed Feb 20 15:34:51 UTC 2019
> The approach taken is focused on fulfilling the business requirements
for natural person identification in the EU. So my
> assumption (and hope) is we together as a WG will refine and enhance the
concept to cover the requirements of jurisdictions around
> the world. I look forward to having productive discussions.
thank you very much for the proposal, which we fully support and, may I
say, even need for our own purposes. Here follows a list of
remarks/questions in no particular order:
- Page 9: Requesting verified person data. All examples reflect requesting
claims for "userinfo" endpoint, but I guess it's perfectly valid doing so
for the ID token. It'd be good to put some explicit text about it (and
maybe even one ID token example).
- Page 10: The role of "max_age" is a bit strange: it is defined as a
"field for the sub-element date of the verification sub-claim" but
it's actually a way of introducing a (hidden) query syntax. When I think
of it, it's an extension of the special three member values defined in
OIDC core section 5.5.1, that is, parallel to the existing reserved
keywords "essential", "value" and "values". Maybe it'd help to explicitly
define it that way. Do you understand what I mean?
- Page 10, also about max_age: "If the verification data of the user is
older than the requested max_age, [the IDP] SHOULD attempt to refresh"
Sincerely, that's too much asking and even a matter of IDP policy if it
wants to refresh or not. As an IDP I wouldn't like to have to trigger
internal (cost-intensive) processes, just because some random RP asks for
any unrealistic max_age. Maybe it all boils down to relaxing the
formulation "SHOULD" to "MAY WANT TO CONSIDER" :-).
- Page 11, "If the RP requested date as essential claim, the IDP will
abort the transaction and respond with the error code
unable_to_meet_requirement" Please excuse my ignorance, there's no
such error code in OIDC Core. Is it defined somewhere else? Is it
something new from this specification?
- Page 11, "The OP advertises its capabilities with respect to verified
person data in the standard openid-configuration using the following
elements". And then verified_person_data_supported and
verification_methods_supported are introduced. But as a matter of fact,
this specification also requires "claims_parameter_supported" to be
advertised and set to true (support is defined as optional in OIDC core
and, per OIDC Discovery, default is false). I think that has to be
- Page 11 introduces "transaction_id" and I was wondering whether this is
the same as the "id" field introduced in page 4 or not, and then would ask
to either align names or explicitly explain the differences.
- Page 12, there's a linked word "verification" that leads to a GDocs I
haven't any access to.
- Page 12, there's still a reference to "qes" JSON string. I think that's
a leftover from a previous doc version.
- Page 7 says "all three verification methods", but it only lists two.
- Page 5: The "identity_document" table has the following introductory
text: "All elements not explicitly marked as optional are mandatory". I'd
also add that intro to the "verification" element in page 3.
- Page 5: Btw, why is "country" optional for identity_document but not for
"eID" (Page 6)?
- And finally we are making heavy use of distributed claims in our setup
and I am having trouble in thinking how the special members _claim_names
and _claim_sources (which also have usage in aggregated claims) would play
along together with this spec. Maybe it's just one further example at the
end that I am missing.
Thanks again for the work you've put together and contribute now to the
More information about the Openid-specs-ab