<div dir="ltr">I believe the commentary in the open issues was about <span class="gmail-issue-id">Issue <a href="https://bitbucket.org/openid/connect/issues/1415">#1415 re-using ID Token as a source of third party attested user-claims</a> rather than #1395 </span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 27, 2022 at 1:20 PM Mike Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" lang="EN-US">
<div class="gmail-m_6445300980431824368WordSection1">
<p class="MsoNormal">Spec Call Notes 27-Jan-22<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">John Bradley<u></u><u></u></p>
<p class="MsoNormal">Giuseppe De Marco<u></u><u></u></p>
<p class="MsoNormal">Joseph Heenan<u></u><u></u></p>
<p class="MsoNormal">Filip Skokan<u></u><u></u></p>
<p class="MsoNormal">Brian Campbell<u></u><u></u></p>
<p class="MsoNormal">Thomas Bellebaum<u></u><u></u></p>
<p class="MsoNormal">Bjorn Hjelm<u></u><u></u></p>
<p class="MsoNormal">David Chadwick<u></u><u></u></p>
<p class="MsoNormal">Kristina Yasuda<u></u><u></u></p>
<p class="MsoNormal">Mike Jones<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Federation Spec Discussions<u></u><u></u></p>
<p class="MsoNormal"> Roland discussed the state of the Federation spec<u></u><u></u></p>
<p class="MsoNormal"> He talked about Tom Jones not liking our use of the term Trust Mark<u></u><u></u></p>
<p class="MsoNormal"> Roland asked if we wanted to rename Trust Marks to Compliance Marks as a compromise<u></u><u></u></p>
<p class="MsoNormal"> John said that what we're calling Trust Marks matches most people's understanding of what a Trust Mark is<u></u><u></u></p>
<p class="MsoNormal"> Our Trust Marks are signed JSON documents. Roland said that Tom thinks they should just be URLs.<u></u><u></u></p>
<p class="MsoNormal"> John doesn't think that Trust Marks being signed JSON would stop the US healthcare system from using them<u></u><u></u></p>
<p class="MsoNormal"> If they want to just use a URL, they can simply pull the URL out of the JSON object<u></u><u></u></p>
<p class="MsoNormal"> Mike pointed out that Tom isn't on the call and we're already discussing this in the issues<u></u><u></u></p>
<p class="MsoNormal"> Giuseppe said that he'd like the decisions to be made soon so the spec is stable<u></u><u></u></p>
<p class="MsoNormal"> We decided on the call not to change the name - see issue #1394<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Federation Issues<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://bitbucket.org/openid/connect/issues?status=new&status=open&component=Federation" target="_blank">
https://bitbucket.org/openid/connect/issues?status=new&status=open&component=Federation</a><u></u><u></u></p>
<p class="MsoNormal"> #1368: [federation_api] fetch entity statement - issuer paramenter is really required?<u></u><u></u></p>
<p class="MsoNormal"> Roland said that this is about leaving an issuer out of the request - not a response<u></u><u></u></p>
<p class="MsoNormal"> John said that the subject you're asking about is always the end entity<u></u><u></u></p>
<p class="MsoNormal"> The party that's proxying the request shouldn't be called the issuer<u></u><u></u></p>
<p class="MsoNormal"> David said that in the TRAIN model, this is called the proxy<u></u><u></u></p>
<p class="MsoNormal"> Mike said it seems like we don't need this request parameter and we shouldn't call it the issuer<u></u><u></u></p>
<p class="MsoNormal"> John said to call it the "resolver"<u></u><u></u></p>
<p class="MsoNormal"> David said that it's important that it be signed by the resolver or the subject<u></u><u></u></p>
<p class="MsoNormal"> John said it's good to say who's asking for debugging purposes, even if that information isn't secured<u></u><u></u></p>
<p class="MsoNormal"> Roland said that the requester should be in the audience<u></u><u></u></p>
<p class="MsoNormal"> Roland agreed to make these changes. After that, we should re-review the descriptions.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Federation PRs<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://bitbucket.org/openid/connect/pull-requests/" target="_blank">
https://bitbucket.org/openid/connect/pull-requests/</a><u></u><u></u></p>
<p class="MsoNormal"> PR #111: Evaluate Entity Statement for any subject<u></u><u></u></p>
<p class="MsoNormal"> Roland said that there is a "list" operation that lists subordinate entities<u></u><u></u></p>
<p class="MsoNormal"> Roland said that the subject parameter is the entity we're asking about<u></u><u></u></p>
<p class="MsoNormal"> That answers Mike's question about how you know what the response is about<u></u><u></u></p>
<p class="MsoNormal"> John asked if we need an on-behalf-of in some cases because the entity isn't the resolver<u></u><u></u></p>
<p class="MsoNormal"> Where in the response is the subject of the query?<u></u><u></u></p>
<p class="MsoNormal"> Roland said that this is the subject claim<u></u><u></u></p>
<p class="MsoNormal"> John said that he would call this the entity<u></u><u></u></p>
<p class="MsoNormal"> This is part of the description to be changed per the discussion of #1368<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Open Issues<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://bitbucket.org/openid/connect/issues?status=new&status=open" target="_blank">
https://bitbucket.org/openid/connect/issues?status=new&status=open</a><u></u><u></u></p>
<p class="MsoNormal"> #1395 usage of id_token_hint in OIDC.Core<u></u><u></u></p>
<p class="MsoNormal"> John said that the wielder would need some kind of proof-of-possession mechanism<u></u><u></u></p>
<p class="MsoNormal"> John asked whether this should even be called an ID Token<u></u><u></u></p>
<p class="MsoNormal"> Brian said that this would be a misuse, requiring ignoring RFC-level REQUIRED security validation actions<u></u><u></u></p>
<p class="MsoNormal"> He thought that having a different token intended for this purpose would be far better<u></u><u></u></p>
<p class="MsoNormal"> David said that the thing we're talking about feels more like a Verifiable Credential<u></u><u></u></p>
<p class="MsoNormal"> Kristina said that there are far more issuers of ID Tokens than VCs at this point<u></u><u></u></p>
<p class="MsoNormal"> John said that what you want is some kind of federated access token - not an ID Token<u></u><u></u></p>
<p class="MsoNormal"> The claims needed can be in the access token<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Outstanding Implementer's Draft Approval Votes<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://openid.net/foundation/members/polls/261" target="_blank">
https://openid.net/foundation/members/polls/261</a> - prompt=create<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://openid.net/foundation/members/polls/266" target="_blank">
https://openid.net/foundation/members/polls/266</a> - SIOPv2 and OIDC4VP<u></u><u></u></p>
<p class="MsoNormal"> Please participate!<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Next Call<u></u><u></u></p>
<p class="MsoNormal"> The next Connect call will be Monday, January 31, 2022 at 3pm Pacific Time<u></u><u></u></p>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.</font></span></i>