<div dir="ltr"><span id="docs-internal-guid-b07cc3d0-b819-4a01-45c4-add3305b797c"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Attending:</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">John Bradley</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Adam Cooper</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Paul Grassi</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Justin Richer</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Mike Varley</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Sarah Squire</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Nat Sakimura</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Mike went over his changes to the spec. He didn’t add anything about holder-of-key or token binding. He did work on defining some scopes that may be interesting for cross-jurisdiction use cases. “Authmode” was removed from authorization request. It’s just a prompt field for now. There’s some talk about using account chooser. Inclusion of the userinfo endpoint was changed to a MUST because if necessary, it can only provide a pseudonymous identifier. We should probably add that reasoning to the text. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">In the use case document, there is some stuff about required attributes in the userinfo endpoint. We should talk about that. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Does it make sense to have a “privacy considerations” section about what we expect a privacy-preserving userinfo endpoint to do? Yes, let’s do that. We can talk about how identifiers are created too.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Do we want to reference metadata claims from connect core? Yes, but we’ll also want to define some sets that are specific to our use cases like documents and biometrics. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">How do we define a minimum set of claims? Well, not every identity provider is going to have every claim. We need to make sure that we’re not inadvertently making them incompatible because they didn’t collect the right information. The relying party should always be prepared to get less than it asked for. UK mandates name, date of birth, and place of birth.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Is there anything in the discovery spec that describes the claims available at the userinfo endpoint? There has been discussion about putting in information about additional claims, but nothing beyond that. There isn’t anything that says “I support this claim, but not that claim.”  There is claim support, but it was intended for extensions. It could be used for this. And we have to be clear that just because a claim is supported doesn’t mean it’s available for all subjects.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Should we say that it’s required to publish your claim schema? Yes. Let’s go with it for now, and see if we get pushback from anyone.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Should we say there’s a recommended minimum claim set to allow for matching? We might want to add “place of birth” scope to the core connect profile. UK has also found history of name and address to be helpful in matching. Paul will look at what the standard bundles are in the US.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Another thing to consider is that the OIDC userinfo profile was designed to transmit self-asserted data. We may want to transmit information about how well vetted the attributes are. Do we allow every trust framework to do their own standard of proofing? Or do we want to reduce the number of attributes by allowing metadata for attribute vetting? We will need an attribute level - how well was this person proofed? And an assertion level - how sure are we that this attribute is accurate?</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">There is a NISTIR (</span><a href="https://pages.nist.gov/NISTIR-8112/NISTIR-8112.html" style="text-decoration:none"><span style="font-size:14.6667px;font-family:Arial;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">NIST Internal Report 8112 Attribute Metadata</span></a><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">) on metadata about attributes. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Mike will add some text about VoT and why it’s important. It would be in the idtoken because it is about the authentication transaction.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">We should talk about discovery and webfinger. We’ll add issues to the bitbucket and talk about it on email.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">We talked about account chooser as one way of doing discovery and using token binding for maintaining LOA 4 across agencies with idtokens, which the EAP working group is also working on. </span></p><br><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">How would account chooser work on Day 1? The static javascript would introspect the local HTML 5 storage and give them a list of account options. “Bring your own NASCAR.” It’s not a replacement for webfinger. It’s possible the user would have a new browser. At that point you’d fall back to webfinger. </span></span><div><font color="#000000" face="Arial"><span style="font-size:14.6667px;white-space:pre-wrap"><br clear="all"></span></font><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(136,136,136)">Sarah Squire</div><div style="color:rgb(136,136,136)">Engage Identity</div><div style="color:rgb(136,136,136)"><a href="http://engageidentity.com/" style="color:rgb(17,85,204)" target="_blank">http://engageidentity.com</a></div></div></div></div>
</div></div>