<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Clarification, ISO 18013-5 DOES use JWT when using the OIDC flows(and in future when 18013-5 uses SIOP), and non-OIDC flows use MSO (mdoc) but use JWS and not JWT.<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, April 8, 2021 11:18 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 8-Apr-21<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Spec Call Notes 8-Apr-21<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Nat Sakimura<o:p></o:p></p><p class=MsoNormal>John Bradley<o:p></o:p></p><p class=MsoNormal>Mike Jones<o:p></o:p></p><p class=MsoNormal>Filip Skokan<o:p></o:p></p><p class=MsoNormal>Vladimir Dzhuvinov<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>Adam Lemmon<o:p></o:p></p><p class=MsoNormal>Tim Cappalli<o:p></o:p></p><p class=MsoNormal>Bjorn Hjelm<o:p></o:p></p><p class=MsoNormal>Oliver Terbu<o:p></o:p></p><p class=MsoNormal>Kristina Yasuda<o:p></o:p></p><p class=MsoNormal>Tom Jones<o:p></o:p></p><p class=MsoNormal>Joseph Heenan<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>OpenID Connect Federation Draft<o:p></o:p></p><p class=MsoNormal> Roland reported on the Federation Draft progress<o:p></o:p></p><p class=MsoNormal> We did three interop events last year<o:p></o:p></p><p class=MsoNormal> There are three independent implementations - by Vladimir Dzhuvinov, Henri Mikkonen, and Roland Hedberg<o:p></o:p></p><p class=MsoNormal> The specification has been iteratively updated to address issues found<o:p></o:p></p><p class=MsoNormal> People had been able to largely implement in an interoperable fashion<o:p></o:p></p><p class=MsoNormal> Issues from Torsten and Brian were also discussed and addressed<o:p></o:p></p><p class=MsoNormal> Leif Johansson pointed out a remaining dependence upon Web PKI<o:p></o:p></p><p class=MsoNormal> jwks_uri uses Web PKI<o:p></o:p></p><p class=MsoNormal> It can be avoided using entity statements with "jwks", but that interferes with key rotation<o:p></o:p></p><p class=MsoNormal> Or we can introduce signed_jwks_uri (which apparently we discussed ~2 years ago)<o:p></o:p></p><p class=MsoNormal> This is in Roland's code<o:p></o:p></p><p class=MsoNormal> Roland has asked Vladimir and Henri to also add it<o:p></o:p></p><p class=MsoNormal> Then they'll do interop on the new feature<o:p></o:p></p><p class=MsoNormal> John recalls the signed jwks_uri discussion<o:p></o:p></p><p class=MsoNormal> John asked about how to trust the signature<o:p></o:p></p><p class=MsoNormal> Vladimir asked if there had been thoughts of using the Accept header<o:p></o:p></p><p class=MsoNormal> John said that we have used metadata parameters instead of that design pattern<o:p></o:p></p><p class=MsoNormal> Mike asked with what key you sign the keys<o:p></o:p></p><p class=MsoNormal> Roland said that the entity statements are self-signed<o:p></o:p></p><p class=MsoNormal> But you're trusting it because the key is protected by the trust chain<o:p></o:p></p><p class=MsoNormal> Roland will create a spec update adding signed_jwks_uri<o:p></o:p></p><p class=MsoNormal> Mike and John will review<o:p></o:p></p><p class=MsoNormal> Roland will ask Vlad and Henri to ask review<o:p></o:p></p><p class=MsoNormal> Next Steps<o:p></o:p></p><p class=MsoNormal> Mike said that we could either do another Implementer's Draft or take the spec to Final status<o:p></o:p></p><p class=MsoNormal> John said that he thought we should do another Implementer's Draft<o:p></o:p></p><p class=MsoNormal> He wants to see the near-final draft be widely circulated<o:p></o:p></p><p class=MsoNormal> Roland reports that Leif is involved in a project that may also be building or deploying it<o:p></o:p></p><p class=MsoNormal> Roland will check in with him<o:p></o:p></p><p class=MsoNormal> John reports that the spec has come up on Internet2 calls<o:p></o:p></p><p class=MsoNormal> Vladimir reports that there are no real deployments yet - just interoperating implementations<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Claims for Verifiable Credentials Objects<o:p></o:p></p><p class=MsoNormal> Mike summarized some recent discussions on using W3C Verifiable Credential objects with JWTs<o:p></o:p></p><p class=MsoNormal> The VC spec defines "vc" and "vp" claims, which are used as part of the W3C-define JWT representations<o:p></o:p></p><p class=MsoNormal> The values of these claims are not complete Verifiable Credential or Verifiable Presentation objects<o:p></o:p></p><p class=MsoNormal> The W3C VC spec defines representations for four things, which are the combinations of two sets of two things each:<o:p></o:p></p><p class=MsoNormal> JWT and JSON-LD representations<o:p></o:p></p><p class=MsoNormal> Verifiable Credential and Verifiable Presentation representations<o:p></o:p></p><p class=MsoNormal> Mike sent a proposal to the working group defining four JWT claims for these four kinds of objects<o:p></o:p></p><p class=MsoNormal> vc_jwt, vp_jwt, vc_ld, and vp_ld<o:p></o:p></p><p class=MsoNormal> John asked where these would be used<o:p></o:p></p><p class=MsoNormal> They could be used in the ID Token, in UserInfo Endpoint responses, and in other sets of IANA JWT claims<o:p></o:p></p><p class=MsoNormal> John asked whether we should overload claims, using the same claims for JWT and JSON-LD representations<o:p></o:p></p><p class=MsoNormal> People were opposed to overloading<o:p></o:p></p><p class=MsoNormal> Mike tried to respond to Tom's e-mail comment about instead using claim names defined for particular use cases<o:p></o:p></p><p class=MsoNormal> Tom talked about ID Proofing versus Authentication Proofing<o:p></o:p></p><p class=MsoNormal> Tom said that healthcare people have turned data structures into strings and put them in amr values<o:p></o:p></p><p class=MsoNormal> Oliver says that VCs contain a type property<o:p></o:p></p><p class=MsoNormal> Kristina said that VCs and VPs are becoming part of identity for some use cases<o:p></o:p></p><p class=MsoNormal> Tom objects to having generic claims, rather than specific claims<o:p></o:p></p><p class=MsoNormal> Tim said that the VP should be in response to a request with a specific set of requirements<o:p></o:p></p><p class=MsoNormal> Tim supports having generic claims<o:p></o:p></p><p class=MsoNormal> Mike reported on RFC 7800 "cnf" claim naming and the possibility of multiple claim names here too<o:p></o:p></p><p class=MsoNormal> Just like use cases can define other claims with the "cnf" syntax,<o:p></o:p></p><p class=MsoNormal> the same could be done here, when needed to distinguish between multiple kinds of W3C VC objects<o:p></o:p></p><p class=MsoNormal> George asked whether we want to have all claims be returned in VCs and VPs<o:p></o:p></p><p class=MsoNormal> Mike said, no, that's not what we're doing<o:p></o:p></p><p class=MsoNormal> Tim said that Presentation Exchange has paths to say where claims should to go<o:p></o:p></p><p class=MsoNormal> <a href="https://identity.foundation/presentation-exchange/">https://identity.foundation/presentation-exchange/</a><o:p></o:p></p><p class=MsoNormal> Tim said that that some use cases will use one or the other<o:p></o:p></p><p class=MsoNormal> Kristina said she views these objects as claims at the same level of things like e-mail<o:p></o:p></p><p class=MsoNormal> George said that he wants to ask for a Mobile Driver's License claim in a format that he can process it<o:p></o:p></p><p class=MsoNormal> He needs to know the format that the claim will be returned in<o:p></o:p></p><p class=MsoNormal> Tom reports that Mobile Driver's Licenses will be in ISO 18013-5 format - not JWTs or VCs<o:p></o:p></p><p class=MsoNormal> John said that there are already four JWT claims formats - JSON, Normal JWT, Aggregated, and Distributed<o:p></o:p></p><p class=MsoNormal> George wants there to be metadata about claims<o:p></o:p></p><p class=MsoNormal> Mike said that Edmund's Claims Aggregation draft does enable claims to be requested in different structures<o:p></o:p></p><p class=MsoNormal> <a href="https://bitbucket.org/openid/connect/src/master/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.md">https://bitbucket.org/openid/connect/src/master/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.md</a><o:p></o:p></p><p class=MsoNormal> Oliver said that registering a small set of claims seems like a next step<o:p></o:p></p><p class=MsoNormal> George wants to be able to request claims in particular formats, and with particular groupings<o:p></o:p></p><p class=MsoNormal> That means that would have to work on richer claims requests syntax<o:p></o:p></p><p class=MsoNormal> Mike said that he's trying to first solve the simple cases<o:p></o:p></p><p class=MsoNormal> George said that this doesn't preclude more complicated cases<o:p></o:p></p><p class=MsoNormal> Mike said he plans to write the tiny spec and explicitly say what it's not doing<o:p></o:p></p><p class=MsoNormal> Tom said that you can't ask all Claims Providers to support VC formats<o:p></o:p></p><p class=MsoNormal> Tom said that he might also write up a parallel spec for generic JOSE claims<o:p></o:p></p><p class=MsoNormal> John said that we already have that: aggregated and distributed claims<o:p></o:p></p><p class=MsoNormal> Tom wants to try to remove things from front-end processing<o:p></o:p></p><p class=MsoNormal> John asks whether we want an external dictionary for VCs like we have for aggregated and distributed claims<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Browser Special Call Report<o:p></o:p></p><p class=MsoNormal> We ran out of time for this<o:p></o:p></p><p class=MsoNormal> Tim did send notes from the call to the list<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">https://bitbucket.org/openid/connect/issues?status=new&status=open</a><o:p></o:p></p><p class=MsoNormal> We ran out of time for this<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> The next regular Connect call is on Monday, April 12th, 2021 at 4pm Pacific Time<o:p></o:p></p></div></body></html>