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

Torsten Lodderstedt torsten at lodderstedt.net
Thu Feb 21 12:51:38 UTC 2019

Hi Marcos, 

> Am 20.02.2019 um 16:34 schrieb Marcos Sanz <sanz at denic.de>:
> 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

Thanks a lot!

> and, may I 
> say, even need for our own purposes.

 That’s what I had hopped for :-)

> 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’s intended to support both options + the option to convey data via the Token Introspection Endpoint

> It'd be good to put some explicit text about it (and 
> maybe even one ID token example).

Noted, will extend the text and add add more examples when (and if) the WG has adopted the document. 

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

I think so. I would argue the whole representation extends the syntax of the claims parameter payload by introducing nested claims + conditions on those nested claims. 

I would appreciate if you would come up with a text proposal. 

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

This very much depends on the underlying price model. If the RP covers the additional cost that shouldn’t be a problem for the IDP. 

Whether the RP really insists on the max age depends on its risk assessment and its interpretation of its legal obligations.

> Maybe it all boils down to relaxing the 
> formulation "SHOULD" to "MAY WANT TO CONSIDER" :-).

Works for me. For me the „SHOULD“ already is rather relaxed (in comparison to a „MUST").

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

You are right. That’s a new error code. I will add it to the error registry in the next revision. 

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

You are right. 

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

That’s a different claim. Id refers to the verification process with the IDP whereas transaction_id refers to the actual OpenID Connect transaction. It’s used to in dispute and audit scenarios to trace back to the OIDC transaction, the OP is supposed to retain an audit log so the authentication and consent steps performed can be followed. 
> - Page 12, there's a linked word "verification" that leads to a GDocs I 
> haven't any access to.

Oops. Thanks!

> - Page 12, there's still a reference to "qes" JSON string. I think that's 
> a leftover from a previous doc version.

Yes, it is. I removed it. We intended to use qualified electronic signatures as means to proof a person’s identity. But it turned out this is too early. 

> - Page 7 says "all three verification methods", but it only lists two.

Same reason - thanks!

> - 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)?

Conceptually, it would be better to make country mandatory as well. But there are cases in the wild where the IDP did not capture the country (because it was clear from the context back then - sometimes 20-30 yrs ago). 

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

Honestly, I haven’t thought about this because of lake of use cases. If you can come up with text, I would happily add it. 

> Thanks again for the work you've put together and contribute now to the 

No problem. Thank a lot for your detailed review. 

best regards,

> Best regards,
> Marcos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3923 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190221/4b766540/attachment.p7s>

More information about the Openid-specs-ab mailing list