<div><div><div dir="auto">Hi Jaap,</div></div><div dir="auto"><br></div><div dir="auto">thanks for your post. Please find my comments inline.</div><div dir="auto"><br></div><div dir="auto">best regards,</div><div dir="auto">Torsten.</div><div><br><div class="gmail_quote"></div></div></div><div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Jaap Francke via Openid-specs-ekyc-ida <<a href="mailto:openid-specs-ekyc-ida@lists.openid.net" target="_blank">openid-specs-ekyc-ida@lists.openid.net</a>> schrieb am Mi. 29. Apr. 2020 um 08:27:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">



<div style="word-wrap:break-word;line-break:after-white-space">
Hi,
<div><br>
</div>
<div>Meanwhile, we’ve signed the IPR paperwork, so I’m re-submitting my feedback.</div>
<div>Kind regards,</div>
<div><br>
</div>
<div>Jaap<br>
<div><br>
<blockquote type="cite">
<div>Begin forwarded message:</div>
<br>
<div style="margin:0px">
<span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">From:
</b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">Jaap Francke <<a href="mailto:jaap.francke@iwelcome.com" style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif" target="_blank">jaap.francke@iwelcome.com</a>><br>
</span></div>
<div style="margin:0px">
<span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">Subject:
</b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif"><b style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">Usage of scopes and purposes when requesting verified claims</b><br>
</span></div>
<div style="margin:0px">
<span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">Date:
</b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">31 March 2020 at 18:01:32 CEST<br>
</span></div>
<div style="margin:0px">
<span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">To:
</b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif"><a href="mailto:openid-specs-ekyc-ida@lists.openid.net" style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif" target="_blank">openid-specs-ekyc-ida@lists.openid.net</a><br>
</span></div>
<br>
<div>
<div style="word-wrap:break-word;line-break:after-white-space">
<div dir="auto" style="word-wrap:break-word;line-break:after-white-space">
<div dir="auto" style="word-wrap:break-word;line-break:after-white-space">
<div>Hi everybody,</div>
<div><br>
</div>
<div>I’m new on this mailing list, thanks for letting me in ;-).</div>
<div>I have potentially missed previous feedback or conversation around the Identity Assurance specification, but that shouldn’t stop me from sharing my views.</div>
<div><br>
</div>
<div>As a Product Manager at iWelcome, I am very interested in Identity Assurance. I’ve been involved in a number of projects where verified claims are a key element to the identity management solution. In the Netherlands, for example, consumer banks
 are using the IDIN schema to act as a claim provider for identity proofing purposes. </div>
<div>This is beneficial to Insurance companies that can sell certain products only to proven identities.</div>
<div><br>
</div>
<div>My feedback on the specs is below, I’m interested to see your responses, thanks.</div>
<div><br>
</div>
<div>Kind regards</div>
<div><br>
</div>
<div>Jaap Francke</div>
<div>CIAM Product manager @ iWelcome.</div>
<div><br>
</div>
<div><br>
</div>
<div>———</div>
<div><br>
</div>
<div><a href="https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html" target="_blank">https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html</a></div>
<div>
<div><br>
</div>
<div>The "OIDC for identity Assurance” specs introduce a number of claims, in addition to the ones specificied by OIDC core.</div>
<div>In OIDC Core, there are 2 mechanisms to request claims:</div>
<div>- one is by usage of OAuth-scopes, (section 5.4 of Core spec)</div>
<div>- one by usage of the “claims” parameter in the request. (section 5.5 of Core spec)</div>
<div>Section 5 of the OIDC—identity-assurance specs indicate the usage of the claims pararameter. This may suggest it’s the only mechanism to be used in the context of Identity Assurance.</div>
<div>My view is that also the ’scope’ mechanism should be supported and may even be preferred for certain use cases.</div>
<div><i><b>Please enhance the specification to be more explicit about usage of scopes as a means to request verified claims.</b></i></div>
<div><br>
</div>
<div>Usage of ’scope’ to request verified claims makes sense to me because in a typical “identity landscape” the requested claims do not vary on a request-by-request basis, but instead are a reflection of an RP’s functionality
 which can be rather static. By pre-defining/configuring scopes at the OP (potentially in terms of ’essential’, ’trust_framework’, etc..), the scope is essentially a profile of the claim request. This would not only simplify the protocol implementation both
 at the RP and OP side, but it would also make it easier for the OP to make the authorisation decision whether or not the RP will be granted the requested verified claims. '<span style="background-color:rgb(255,255,255)"><font face="Noto Sans, Arial, Helvetica, sans-serif" style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><span style="font-size:14px;font-family:"Noto Sans",Arial,Helvetica,sans-serif">It
 is at the discretion of the OP to decide whether the requested verification data is provided to the RP.</span><span style="font-size:14px;font-family:"Noto Sans",Arial,Helvetica,sans-serif">’</span><span style="font-size:14px;font-family:"Noto Sans",Arial,Helvetica,sans-serif"> Making this decision is much easier when a request includes
 a scope as a reference to a predefined profile of requested end-user claims and associated verification data.
<i style="font-family:"Noto Sans",Arial,Helvetica,sans-serif"><b style="font-family:"Noto Sans",Arial,Helvetica,sans-serif">My suggestion is to consider including such a mechanism in the specifications.</b></i></span></font></span></div>
<div><span style="background-color:rgb(255,255,255)"><font face="Noto Sans, Arial, Helvetica, sans-serif" style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><span style="font-size:14px;font-family:"Noto Sans",Arial,Helvetica,sans-serif"></span></font></span></div></div></div></div></div></div></blockquote></div></div></div></blockquote><div dir="auto"><br></div></div></div></div><div><div><div class="gmail_quote"><div dir="auto">What do you have in mind? I agree a certain RP or deployment could define scope values as short cut to request certain verified claims. However, the number and value range of verification elements + the number of end user claims creates is so big I cannot envision how the spec could define concrete scope values. Additionally, the spec no longer defines values for trust frameworks, verification methods and evidence, i.e. there are unknown values from a spec perspective.</div></div></div></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div><div><span style="background-color:rgb(255,255,255)"><font face="Noto Sans, Arial, Helvetica, sans-serif" style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><span style="font-size:14px;font-family:"Noto Sans",Arial,Helvetica,sans-serif"><br>
</span></font></span></div>
<div><span style="background-color:rgb(255,255,255)"><font face="Noto Sans, Arial, Helvetica, sans-serif" style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><span style="font-size:14px;font-family:"Noto Sans",Arial,Helvetica,sans-serif">My second observation is about the
 optional ‘purpose’ parameter in a claims request. The specs state that </span></font></span><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255);color:rgb(34,34,34)">the
 OP MUST display this purpose in the respective user consent screen(s) in order to inform the user about the designated use of the data to be transferred or the authorization to be approved. If the parameter </span><code style="font-family:"Roboto Mono",monospace;font-size:13.3px;font-variant-ligatures:normal;background-color:rgb(249,249,249);color:rgb(34,34,34)">purpose</code><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255);color:rgb(34,34,34)"> is
 not present in the request, the OP MAY display a value that was pre-configured for the respective RP.’ </span></div>
<div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255);color:rgb(34,34,34)">This part of the specification
 assumes or seems to imply that the user gets a consent screen every time that verified data is requested. I think that this is not realistic:</span></div>
<div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255);color:rgb(34,34,34)">- it is common practice
 that certain consents are included in a Privacy Policy (PP) and/or Terms of Service (ToS). The user gives his consent once and the consent is persisted at the OP for future purposes.</span></div></div></div></div></div></div></blockquote></div></div></div></blockquote><div dir="auto"><br></div></div><div><div dir="auto">Are you referring to ToS/PP of the RP or the OP?</div></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255);color:rgb(34,34,34)"></span></div>
<div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255);color:rgb(34,34,34)">- if not in PP or ToS,
 a consent screen may be presented only ‘once’ and the user’s consent is taken to be valid for the next 6 months (as an example)</span></div>
<div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255);color:rgb(34,34,34)">- in some situations there
 are other legal grounds/reasons/purposes to request the claims and verification data. Besides ‘consent’, the European GDPR indicates other legal grounds (contract, vital interest, legal obligation, ..). When an RP asks for a verified claim, it may do so based
 on a legal obligation and the user’s consent would not be needed.</span></div>
<div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255);color:rgb(34,34,34)">- Privacy regulations
 aim at situations where personal data is exchanged between legal entities (data controllers, data processors). From an IT perspective, the OP and the RP may be operated by the same entity (for example an Insurance company as data controller that is both the
 data controller for the OP and various RPs) so consent would not apply at the moment of requesting the claim. The consent should already have been given at the moment the personal data was provided to the OP.</span></div>
<div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255);color:rgb(34,34,34)"><b style="font-family:"Noto Sans",Arial,Helvetica,sans-serif"><i style="font-family:"Noto Sans",Arial,Helvetica,sans-serif">My
 proposal would be that the ‘purpose’ could be a string (as per current specification) or a reference to a ‘purpose’ that has already been established somewhere.</i></b> This approach makes it easier for the OP to make the decision to provide the requested
 data or not.</span></div></div></div></div></div></div></blockquote></div></div></div></blockquote><div dir="auto"><br></div></div><div><div dir="auto">I agree the text is too strong. The purpose should be used to further inform the user in case a user consent screen is required. I will try to change the text accordingly.</div></div><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255);color:rgb(34,34,34)"></span></div>
<div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255);color:rgb(34,34,34)"><br>
</span></div>
<div><font face="Noto Sans, Arial, Helvetica, sans-serif" style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><span style="font-size:14px;font-family:"Noto Sans",Arial,Helvetica,sans-serif;background-color:rgb(255,255,255)"><b style="font-family:"Noto Sans",Arial,Helvetica,sans-serif"><i style="font-family:"Noto Sans",Arial,Helvetica,sans-serif">Furthermore, it could be considered
 to extend the list of verification methods with the ones defined by NISTIR 8112.</i></b></span></font></div></div></div></div></div></div></blockquote></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">You mean „Document Verification”, “Record Verification”, “Document Verification with Record Verification”, <span style="border-color:rgb(0,0,0)">“Proof of Possession”, “Probabilistic Verification”, „Not Verified”? We could add this to our Wiki. May I ask you to add the values?</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div><div><font face="Noto Sans, Arial, Helvetica, sans-serif" style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><span style="font-size:14px;font-family:"Noto Sans",Arial,Helvetica,sans-serif;background-color:rgb(255,255,255)"><b style="font-family:"Noto Sans",Arial,Helvetica,sans-serif"><i style="font-family:"Noto Sans",Arial,Helvetica,sans-serif"></i></b></span></font></div></div></div></div></div></div></blockquote></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>

-- <br>
Openid-specs-ekyc-ida mailing list<br>
<a href="mailto:Openid-specs-ekyc-ida@lists.openid.net" target="_blank">Openid-specs-ekyc-ida@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida</a><br>
</blockquote></div></div>
</div>