[Openid-specs-ab] OpenID Connect for Identity Proofing (Proposal)

Marcos Sanz sanz at denic.de
Wed Feb 20 15:34:51 UTC 2019


Hi Torsten,

> 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 
explicitly stated.

- 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 
OIDF

Best regards,
Marcos


More information about the Openid-specs-ab mailing list