[Openid-specs-ab] OpenID Connect for Identity Assurance Feedback

[Tobias Looker]

Hi Torsten,

See below for some questions and or feedback on the Identity Assurance
Specification.

General Feedback

Usage of the words OPTIONAL and REQUIRED throughout the specification to
denote elements appears inconsistent? Suggestion would be to use an
explicit convention throughout, e.g for each field definition, prefix the
definition with REQUIRED or OPTIONAL. See Section 4.1
`time`, `verification_process` definitions for examples of fields missing
this clarity at the moment.

Section 4.1.1

- Should the definition of the evidence type be fully qualified URIs or
URNs?
- Should this section include a brief statement about adding new types of
evidence?

Section 5

I found this section harder to follow when I first read it because of the
different approach to the structure of this section in comparison to
section 4. For example section 4 defined the `verified data` representation
at the start then addressed the different elements in the data structure in
accordance with how they were defined. However section 5 introduces the
structure of the `verified data request` in a staged form of increasingly
complicated request examples which makes it harder to understand what the
overall semantics around the request look like. My advice would be to
re-structure section 5 like section 4, then include examples after the
section that show the different types of requests that can be made?

Section 5.2

- Presently there is no firm link between the items of evidence provided
and how it relates to the verified claims (e.g which claims were extracted
from which pieces of evidence) After speaking to you at IIW about this I
understand the reasoning, however adding language to the spec about why
this explicit linkage is not featured, could help clarify? Something along
the lines of, when multiple pieces of evidence are used for a set of
claims, the assumption is that the evidence about the claims is consistent,
e.g with example 6.2 my name on my utility bill and id document were the
same.

- Could the date of verification not be per piece of evidence, rather than
for the entire verification process?

Section 5.3

- The default behavior of `claims=null` being interpreted as a request for
all verified claims by the provider feels like potentially dangerous
default behavior from a data minimization perspective? Because the
supported verified claims are discover-able as meta-data from the OP's
well-known endpoint, it feels appropriate to induce the constraint that the
RP should be explicit about the scope of their request?

Thanks,
[image: Mattr website] <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker at mattr.global
[image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
<https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
<https://twitter.com/mattrglobal> [image: Mattr on Github]
<https://github.com/mattrglobal>
This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20191014/cf3af6fc/attachment.html>