<html 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=utf-8"><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;}
/* 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:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>It was not clear from what torsten said as to the specific legal justification. Was it EU law, or just German law. As I stated before, passing data when what is required is proofing, seems to be an explicit violation of the GDPR. Unless perhaps legal necessity over-rides technical necessity.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>thx ..tom</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:openid-specs-ab@lists.openid.net">Anthony Nadalin via Openid-specs-ab</a><br><b>Sent: </b>Thursday, February 14, 2019 8:51 AM<br><b>To: </b><a href="mailto:openid-specs-ab@lists.openid.net">Artifact Binding/Connect Working Group</a><br><b>Cc: </b><a href="mailto:tonynad@microsoft.com">Anthony Nadalin</a><br><b>Subject: </b>Re: [Openid-specs-ab] Spec Call Notes 14-Feb-19</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This has been discussed in depth at ISO as Nat knows, there are no real agreements between jurisdictions, it’s not the claims that drive the business cases it’s the provenance of the data and how the data was collected, which is outside the verifiable claims, this is the same issue that the W3C WG faces, is that a verifiable claim may mean nothing without the provenance and process<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net> <b>On Behalf Of </b>Mike Jones via Openid-specs-ab<br><b>Sent:</b> Thursday, February 14, 2019 8:31 AM<br><b>To:</b> openid-specs-ab@lists.openid.net<br><b>Cc:</b> Mike Jones <Michael.Jones@microsoft.com><br><b>Subject:</b> [Openid-specs-ab] Spec Call Notes 14-Feb-19<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Spec Call Notes 14-Feb-19<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Brian Campbell<o:p></o:p></p><p class=MsoNormal>George Fletcher<o:p></o:p></p><p class=MsoNormal>Jeff Lombardo<o:p></o:p></p><p class=MsoNormal>Rich Levinson<o:p></o:p></p><p class=MsoNormal>Roland Hedberg<o:p></o:p></p><p class=MsoNormal>Torsten Lodderstedt<o:p></o:p></p><p class=MsoNormal>Mike Jones<o:p></o:p></p><p class=MsoNormal>Nat Sakimura<o:p></o:p></p><p class=MsoNormal>George Fletcher<o:p></o:p></p><p class=MsoNormal>Tom Jones<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>OpenID Connect for Identity Proofing<o:p></o:p></p><p class=MsoNormal> Torsten submitted a draft this week<o:p></o:p></p><p class=MsoNormal> [Openid-specs-ab] OpenID Connect for Identity Proofing (Proposal)<o:p></o:p></p><p class=MsoNormal> The extension can convey user data and assurance, methods, processes, and evidence<o:p></o:p></p><p class=MsoNormal> There is need for this kind of strong identity proofing<o:p></o:p></p><p class=MsoNormal> There is a need to specify which claims are verified<o:p></o:p></p><p class=MsoNormal> And to convey both verified and non-verified claims<o:p></o:p></p><p class=MsoNormal> Torsten is using this for anti money laundering, for instance<o:p></o:p></p><p class=MsoNormal> The requirements are written down in the introduction<o:p></o:p></p><p class=MsoNormal> The extension has two parts<o:p></o:p></p><p class=MsoNormal> Definition of additional claims<o:p></o:p></p><p class=MsoNormal> Such as place of birth<o:p></o:p></p><p class=MsoNormal> Syntax and semantics for requesting and providing verified claims<o:p></o:p></p><p class=MsoNormal> People are requested to review the doc by the Feb 28 call in two weeks<o:p></o:p></p><p class=MsoNormal> We will adopt it then unless objections are voiced<o:p></o:p></p><p class=MsoNormal> Nat: Minimum viable Electronic Know Your Customer (EKYC) work is being done in the EU<o:p></o:p></p><p class=MsoNormal> We should align with that work<o:p></o:p></p><p class=MsoNormal> The chair Stephane G Mouy is willing to work with us<o:p></o:p></p><p class=MsoNormal> Presentations:<o:p></o:p></p><p class=MsoNormal> <a href="https://www.dropbox.com/s/ls28l1ps53u2u2b/3.%20%20PriGroup%202%20Minimum%20Viable%20eKYC%20Framework%20Presentation%20-%20Final2%20%28002%29.pdf.pdf?dl=0"><span style='color:#0563C1'>https://www.dropbox.com/s/ls28l1ps53u2u2b/3.%20%20PriGroup%202%20Minimum%20Viable%20eKYC%20Framework%20Presentation%20-%20Final2%20%28002%29.pdf.pdf?dl=0</span></a><o:p></o:p></p><p class=MsoNormal> <a href="https://www.dropbox.com/s/b4egx1gxma8xh9x/LoA-rated%20Attribute%20Framework%20Proposal%20-%2020181017.pdf?dl=0"><span style='color:#0563C1'>https://www.dropbox.com/s/b4egx1gxma8xh9x/LoA-rated%20Attribute%20Framework%20Proposal%20-%2020181017.pdf?dl=0</span></a><o:p></o:p></p><p class=MsoNormal> The EKYC effort will report by the end of June to the EIDAS group in the EU<o:p></o:p></p><p class=MsoNormal> Torsten agrees that we should work with people from multiple jurisdictions<o:p></o:p></p><p class=MsoNormal> Nat: The EU plan is to have the claims provider be separate from the IdP<o:p></o:p></p><p class=MsoNormal> Torsten is using this in practice<o:p></o:p></p><p class=MsoNormal> The RP requests only the claims that it needs - in accordance with GDPR<o:p></o:p></p><p class=MsoNormal> A multi-faceted discussion of legal and regulatory requirements occurred<o:p></o:p></p><p class=MsoNormal> EU law requires that the recipient acquire specific claims about the verification<o:p></o:p></p><p class=MsoNormal> The US AAMVA, however, requires that proofing be verified but the proofing data need not be acquired<o:p></o:p></p><p class=MsoNormal> Different jurisdictions will use different procedures and legal frameworks<o:p></o:p></p><p class=MsoNormal> George: What we're largely discussing is differences in business requirements<o:p></o:p></p><p class=MsoNormal> Mike: It's up to implementers and deployers to comply with local legal and business requirements<o:p></o:p></p><p class=MsoNormal> We as spec writers should supply tools helping them do that<o:p></o:p></p><p class=MsoNormal> Nat: What we write needs to be globally relevant<o:p></o:p></p><p class=MsoNormal> Torsten: We need to collect use cases from different jurisdictions<o:p></o:p></p><p class=MsoNormal> Nat: In Japan, OIDF-J is doing EKYC work<o:p></o:p></p><p class=MsoNormal> Nat asked whether this should be in the Connect WG or another one<o:p></o:p></p><p class=MsoNormal> Mike said that the claims request and response syntax is an extension to Connect, so belongs here<o:p></o:p></p><p class=MsoNormal> We should seek broad legal and policy review as we're doing the work<o:p></o:p></p><p class=MsoNormal> Tom asked us to consider use cases in which additional information is requested outside the Connect authentication flow<o:p></o:p></p><p class=MsoNormal> Torsten: Distributed claims can be used for this<o:p></o:p></p><p class=MsoNormal> George: An attribute provider endpoint is different from the UserInfo Endpoint<o:p></o:p></p><p class=MsoNormal> Nat: We should define a mechanism for onboarding claims providers to OPs<o:p></o:p></p><p class=MsoNormal> Torsten: EIDAS imposes very specific legal requirements about verification processes and participants<o:p></o:p></p><p class=MsoNormal> Torsten particularly asks everyone to review the requirements in the introduction<o:p></o:p></p><p class=MsoNormal> We're tackling a multi-dimensional problem<o:p></o:p></p><p class=MsoNormal> Nat: This tackles one of the largest cost factors for financial institutions<o:p></o:p></p><p class=MsoNormal> Torsten: This is true of anyone going digital, such as utilities, etc.<o:p></o:p></p><p class=MsoNormal> Torsten asked if SecureKey can inform the working group of what the approach they're taking with IBM is<o:p></o:p></p><p class=MsoNormal> Jeff agreed to look into this<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Federation Draft<o:p></o:p></p><p class=MsoNormal> Roland told us that in the new federation draft, Federation Operators and other participants can enforce policy<o:p></o:p></p><p class=MsoNormal> For instance, only using EC crypto rather than RSA crypto<o:p></o:p></p><p class=MsoNormal> A new policy language has been incorporated that's informed by requirements from specific use cases<o:p></o:p></p><p class=MsoNormal> Mike plans to publish the editor's draft to openid.net/specs/ draft 07 today<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Open Issues<o:p></o:p></p><p class=MsoNormal> <a href="https://bitbucket.org/openid/connect/issues?status=new&status=open"><span style='color:#0563C1'>https://bitbucket.org/openid/connect/issues?status=new&status=open</span></a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal> #1029 - authentication_failed error response<o:p></o:p></p><p class=MsoNormal> Torsten wrote a proposed draft doing this<o:p></o:p></p><p class=MsoNormal> Nat requested that Torsten send an HTML attachment of the draft<o:p></o:p></p><p class=MsoNormal> We can then make an adoption decision on the call in two weeks<o:p></o:p></p><p class=MsoNormal> #1046 - Core 3.1.2.1. - id_token_hint<o:p></o:p></p><p class=MsoNormal> Torsten asks us to sanction passing an ID Token as a login_hint value<o:p></o:p></p><p class=MsoNormal> We will discuss this more on the next call<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Next Call<o:p></o:p></p><p class=MsoNormal> 3pm Pacific Time on Monday, February 18th<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>