<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
samp
{mso-style-priority:99;
font-family:"Courier New";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Thanks for working on this, Torsten and Daniel. I’m excited about the possibilities that this spec opens up! I read
<a href="https://openid.net/specs/openid-connect-4-identity-assurance-04.html">https://openid.net/specs/openid-connect-4-identity-assurance-04.html</a> cover-to-cover. The issues that I’d like to see addressed follow, broken into substantive and editorial
issue sets.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">SUBSTANTIVE ISSUES<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">All Sections: Generalize kinds of verified claims. The most important issue is to generalize the goal of the document from defining how to use “verified person data” to defining how to use “verified data”. This work isn’t happening in
a vacuum. There are other efforts to define representations of verified claims in the industry, including
<a href="https://w3c.github.io/vc-data-model/">https://w3c.github.io/vc-data-model/</a>, that take this more general approach, but propose much more complicated data representations that are not based on JWTs. It would be highly beneficial to have a simple
general JWT-based “verified data” representation that is general-purpose. Indeed, that’s the possibility that excites me about this work. Don’t get me wrong – I believe that all the particulars for verified people data can and should remain. The main concrete
change needed is to rename “<samp><span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black">verified_person_data</span></samp>” to “<samp><span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black">verified_data</span></samp>”.
And of course, the descriptive text needs to be similarly generalized (while still pointing out that specific data structures for verified person data are defined by the specification).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Many Sections: Enable signed evidence. I believe that there will be use cases in which it will be important to be able to have portions of the representations be signed by a party other than the OP. Note that you already have an “issuer”
in some cases. It would be good if the issuer could sign the pertinent data. For instance, there are electronic driver’s license standards in the works using JWTs. It would be good to be able to carry an electronic driver’s license JWT as part of the verification
data. (Might we able to do this by using aggregated claims, or something close to that?)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Status of This Memo: Incorrect IPR language. The document contains an IETF IPR statement, rather than an OpenID one. Please include ipr="none" in the <rfc …> element to turn off the IETF IPR language and add the missing “Notices” section
containing the OpenID Foundation copyright, etc.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Introduction: Generalize “strong identity verification of a natural person” language along the lines of “strong verification of identity information, including information about natural persons”. Similarly generalize the abstract.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Introduction, etc.: The exposition uses the term “authentication assurance”, which is not defined, and for which the meaning isn’t clear. Either add the term to the terminology section or reword to not use that term.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Introduction, etc.: Add “and for the OP to represent the identity assurance data” at the end of the last sentence of the section.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Scope and Requirements: Misuse of “SHALL”, “MAY”, etc. The RFC 2119 keywords such as “SHALL” are intended to be used to define testable requirements of implementations. In this section, “SHALL” is instead used to express the intent
of the specification – not requirements on implementations. Please remove all such uses of RFC 2119 keywords. For instance, reword “The extension specified in this document SHALL” to “The extension specified in this document is intended to”. Similarly,
reword “SHALL allow” to “allows”, etc.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Scope and Requirements: Add a citation after the term “Anti Money Laundering Law”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">3. User Claims: Replace “birth_name” with “birth_family_name”, “birth_given_name”, and “birth_middle_name”. For an example of why this is needed, my eldest daughter Gwen legally changed her name from “Gweneth Lynn Jones” to “Gwendolyn
Rose Jones” before she got her first driver’s license. And my youngest daughter will get married later this year, changing her last name as a result.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">3.2 transaction_id: Replace all uses of “transaction_id” with “txn” – a JWT claim already registered at
<a href="https://www.iana.org/assignments/jwt/jwt.xhtml#claims">https://www.iana.org/assignments/jwt/jwt.xhtml#claims</a> for exactly this purpose.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4.1. verification Element: Add a reference for “eIDAS”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4.1. verification Element: Add a reference for “ISO 8601:2004”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4.1.1.1. id_document: The term “CONDITIONALLY REQUIRED” is not defined and the intended meaning isn’t clear. Reword in the way the OpenID Connect Core expresses such conditional requirements. For example, “<span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black;background:white">REQUIRED
if the Authorization Request included the </span><tt><span style="font-size:12.0pt;font-family:""",serif;color:#003366">state</span></tt><span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black;background:white"> parameter</span>”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">5.2. Defining constraints on requested data: Change “<span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black;background:lightyellow">"max_age":"63113852"</span>” to “<span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black;background:lightyellow">"max_age":63113852</span>”
(removing the quotation marks around the value), since max_age is a number – not a string.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">8. Transaction-specific Purpose: The internationalization characteristics of the “purpose” string should be described. For instance, what locale/language is the string may the string be in? How is the language/locale determined between
the OP and the RP? For instance is the “ui_locale” parameter used and if so, is it required in the request?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">13. JSON Schema, etc.: A clear statement should be made where data structures are being defined that values that are not understood MUST be ignored. This is what will enable extensibility of the JSON over time. The JSON Schema should
reflect this as well, if it is retained. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">13. JSON Schema: I would suggest deleting the JSON Schema entirely, as having two normative definitions of the same data structures can only lead to conflicts and inconsistencies as the specification evolves. Note that other OpenID Connect
specifications manage to unambiguously define normative data structures without the need for JSON Schema. I don’t think it adds value here as well. (And if it does, anything expressed in the schema that is not expressed in the prose should also be normatively
stated in the prose.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">EDITORIAL ISSUES<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Specification version identifier: OpenID documents typically include “1.0” in the title and represent the version number with “-1_0” in the document identifier. Please change the document identifier to “openid-connect-4-identity-assurance-1_0”
and add “1.0” to the end of the title.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Introduction, etc.: The English plural of “evidence” is “evidence” (without an “s”). It’s incredibly jarring to see “evidences” where what is meant is “evidence”. Please change all occurrences of “evidences” to “evidence”. (Another
such example of this in English is the word “knowledge” – which is used in both singular and plural contexts.) This occurs in many sections of the document.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Introduction: Change “that is defined in this specification” to “, which is defined in this specification”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Introduction: Change “a certain OpenID Connect transaction” to “an OpenID Connect transaction”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Introduction: Put commas around the phrase “<span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black;background:white">as defined in Section 2 of the OpenID Connect specification
</span><a href="https://openid.net/specs/openid-connect-4-identity-assurance-04.html#OpenID"><span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:#0066CC;text-decoration:none">[OpenID]</span></a>”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Scope and Requirements: Change the comma to a semicolon in “<span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black;background:white">This extension MAY introduce new user claims to cover user attributes not currently
covered by OpenID Connect, one example would be the place of birth.</span>” so that it is no longer a run-on sentence. (And fix the incorrect use of “MAY”.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Scope and Requirements: Change “User Info” to “UserInfo”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Scope and Requirements: There should always be a comma after “For example”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Scope and Requirements: Change “in case of eIDAS” to “in the case of eIDAS”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Scope and Requirements: Delete “basically”, as it doesn’t add to the meaning of the sentence.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Scope and Requirements: Change “Note: data transfer” to “Note: Data transfer”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">3.1 User Claims: Change “User Claims” to “Claims About the End-User” in the section title. Likewise change all occurrences of “user data” to “data about the end-user” and all occurrences of “user claims” to “Claims about the End-User”.
This aligns the terminology with that used by OpenID Connect.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">3.2 transaction_id: Replace “<span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black;background:white">the claims parameter</span>” with “<span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black;background:white">the
<spanx style="verb">claims</spanx> parameter</span>” so that the protocol element “claims” is appropriately formatted in the output. Likewise, add spanx style verb to all other places where parameter names appear in the document.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4. Verified Data Representation: Change “mixup” to “mix up”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4. Verified Data Representation: Change “section JSON Schema” to “<xref target="JSONSchema"/>” (or whatever the right anchor tag is) so that xml2rfc emits a “Section 13” section link. (Use the Markdown syntax “# JSON Schema # {#JSONSchema}”
to generate the anchor tag for the section title.) Likewise, change all other ASCII section name references to xrefs so that section number links are emitted.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4.1. verification Element: “defined in Trust Frameworks” is another example of a section reference that needs to use xref.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4.1. verification Element: Change “id” to “verification_process” or another suitable identifier that is not “id”. The “id” identifier is widely used by the Facebook graph and other JSON data structures as the primary key for database
lookup of the object. (This is so widely used that we should probably mark it as reserved in the JWT Claims registry.) Attempting to reuse this identifier would only lead to trouble.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4.1.1.1. id_document: This is a run-on sentence: “<span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black;background:white">The method used to verify the id document, predefined values are given in
</span><a href="https://openid.net/specs/openid-connect-4-identity-assurance-04.html#predefined_values_vm"><span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:#0066CC;text-decoration:none">Verification Methods</span></a>”. Change the comma
to a period or semicolon and add a period to the end. The sentence after “type” likewise needs to change the comma to a period.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">5. Requesting Verified Person Data: Change the title of this section to “Requesting Verified Claims”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">5.1. Requesting User Claims: Change the title of this section to “Requesting Verified Claims About the End-User”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">6. Examples: Change “<span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black;background:white">The third section illustrate</span>” to “<span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black;background:white">The
third section illustrates</span>”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">6.1. id_document: Add a “region” value to the place_of_birth example. Likewise in 6.3.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">8. Transaction-specific Purpose: Change instances of “IDP” to “OP”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">12. Predefined Values: A blank line is needed after each (Identifier, Definition) pair to increase readability of the tables.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> Thanks,<o:p></o:p></p>
<p class="MsoNormal"> -- Mike<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>