<div dir="ltr">by jws may i assume you mean 3-part jose?<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">Be the change you want to see in the world </span>..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 8, 2021 at 4:46 PM nadalin--- 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 lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_5696961044798426891WordSection1"><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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b>From:</b> Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>> <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> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br><b>Cc:</b> Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><br><b>Subject:</b> [Openid-specs-ab] Spec Call Notes 8-Apr-21<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Spec Call Notes 8-Apr-21<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Nat Sakimura<u></u><u></u></p><p class="MsoNormal">John Bradley<u></u><u></u></p><p class="MsoNormal">Mike Jones<u></u><u></u></p><p class="MsoNormal">Filip Skokan<u></u><u></u></p><p class="MsoNormal">Vladimir Dzhuvinov<u></u><u></u></p><p class="MsoNormal">Brian Campbell<u></u><u></u></p><p class="MsoNormal">George Fletcher<u></u><u></u></p><p class="MsoNormal">Adam Lemmon<u></u><u></u></p><p class="MsoNormal">Tim Cappalli<u></u><u></u></p><p class="MsoNormal">Bjorn Hjelm<u></u><u></u></p><p class="MsoNormal">Oliver Terbu<u></u><u></u></p><p class="MsoNormal">Kristina Yasuda<u></u><u></u></p><p class="MsoNormal">Tom Jones<u></u><u></u></p><p class="MsoNormal">Joseph Heenan<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">OpenID Connect Federation Draft<u></u><u></u></p><p class="MsoNormal"> Roland reported on the Federation Draft progress<u></u><u></u></p><p class="MsoNormal"> We did three interop events last year<u></u><u></u></p><p class="MsoNormal"> There are three independent implementations - by Vladimir Dzhuvinov, Henri Mikkonen, and Roland Hedberg<u></u><u></u></p><p class="MsoNormal"> The specification has been iteratively updated to address issues found<u></u><u></u></p><p class="MsoNormal"> People had been able to largely implement in an interoperable fashion<u></u><u></u></p><p class="MsoNormal"> Issues from Torsten and Brian were also discussed and addressed<u></u><u></u></p><p class="MsoNormal"> Leif Johansson pointed out a remaining dependence upon Web PKI<u></u><u></u></p><p class="MsoNormal"> jwks_uri uses Web PKI<u></u><u></u></p><p class="MsoNormal"> It can be avoided using entity statements with "jwks", but that interferes with key rotation<u></u><u></u></p><p class="MsoNormal"> Or we can introduce signed_jwks_uri (which apparently we discussed ~2 years ago)<u></u><u></u></p><p class="MsoNormal"> This is in Roland's code<u></u><u></u></p><p class="MsoNormal"> Roland has asked Vladimir and Henri to also add it<u></u><u></u></p><p class="MsoNormal"> Then they'll do interop on the new feature<u></u><u></u></p><p class="MsoNormal"> John recalls the signed jwks_uri discussion<u></u><u></u></p><p class="MsoNormal"> John asked about how to trust the signature<u></u><u></u></p><p class="MsoNormal"> Vladimir asked if there had been thoughts of using the Accept header<u></u><u></u></p><p class="MsoNormal"> John said that we have used metadata parameters instead of that design pattern<u></u><u></u></p><p class="MsoNormal"> Mike asked with what key you sign the keys<u></u><u></u></p><p class="MsoNormal"> Roland said that the entity statements are self-signed<u></u><u></u></p><p class="MsoNormal"> But you're trusting it because the key is protected by the trust chain<u></u><u></u></p><p class="MsoNormal"> Roland will create a spec update adding signed_jwks_uri<u></u><u></u></p><p class="MsoNormal"> Mike and John will review<u></u><u></u></p><p class="MsoNormal"> Roland will ask Vlad and Henri to ask review<u></u><u></u></p><p class="MsoNormal"> Next Steps<u></u><u></u></p><p class="MsoNormal"> Mike said that we could either do another Implementer's Draft or take the spec to Final status<u></u><u></u></p><p class="MsoNormal"> John said that he thought we should do another Implementer's Draft<u></u><u></u></p><p class="MsoNormal"> He wants to see the near-final draft be widely circulated<u></u><u></u></p><p class="MsoNormal"> Roland reports that Leif is involved in a project that may also be building or deploying it<u></u><u></u></p><p class="MsoNormal"> Roland will check in with him<u></u><u></u></p><p class="MsoNormal"> John reports that the spec has come up on Internet2 calls<u></u><u></u></p><p class="MsoNormal"> Vladimir reports that there are no real deployments yet - just interoperating implementations<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Claims for Verifiable Credentials Objects<u></u><u></u></p><p class="MsoNormal"> Mike summarized some recent discussions on using W3C Verifiable Credential objects with JWTs<u></u><u></u></p><p class="MsoNormal"> The VC spec defines "vc" and "vp" claims, which are used as part of the W3C-define JWT representations<u></u><u></u></p><p class="MsoNormal"> The values of these claims are not complete Verifiable Credential or Verifiable Presentation objects<u></u><u></u></p><p class="MsoNormal"> The W3C VC spec defines representations for four things, which are the combinations of two sets of two things each:<u></u><u></u></p><p class="MsoNormal"> JWT and JSON-LD representations<u></u><u></u></p><p class="MsoNormal"> Verifiable Credential and Verifiable Presentation representations<u></u><u></u></p><p class="MsoNormal"> Mike sent a proposal to the working group defining four JWT claims for these four kinds of objects<u></u><u></u></p><p class="MsoNormal"> vc_jwt, vp_jwt, vc_ld, and vp_ld<u></u><u></u></p><p class="MsoNormal"> John asked where these would be used<u></u><u></u></p><p class="MsoNormal"> They could be used in the ID Token, in UserInfo Endpoint responses, and in other sets of IANA JWT claims<u></u><u></u></p><p class="MsoNormal"> John asked whether we should overload claims, using the same claims for JWT and JSON-LD representations<u></u><u></u></p><p class="MsoNormal"> People were opposed to overloading<u></u><u></u></p><p class="MsoNormal"> Mike tried to respond to Tom's e-mail comment about instead using claim names defined for particular use cases<u></u><u></u></p><p class="MsoNormal"> Tom talked about ID Proofing versus Authentication Proofing<u></u><u></u></p><p class="MsoNormal"> Tom said that healthcare people have turned data structures into strings and put them in amr values<u></u><u></u></p><p class="MsoNormal"> Oliver says that VCs contain a type property<u></u><u></u></p><p class="MsoNormal"> Kristina said that VCs and VPs are becoming part of identity for some use cases<u></u><u></u></p><p class="MsoNormal"> Tom objects to having generic claims, rather than specific claims<u></u><u></u></p><p class="MsoNormal"> Tim said that the VP should be in response to a request with a specific set of requirements<u></u><u></u></p><p class="MsoNormal"> Tim supports having generic claims<u></u><u></u></p><p class="MsoNormal"> Mike reported on RFC 7800 "cnf" claim naming and the possibility of multiple claim names here too<u></u><u></u></p><p class="MsoNormal"> Just like use cases can define other claims with the "cnf" syntax,<u></u><u></u></p><p class="MsoNormal"> the same could be done here, when needed to distinguish between multiple kinds of W3C VC objects<u></u><u></u></p><p class="MsoNormal"> George asked whether we want to have all claims be returned in VCs and VPs<u></u><u></u></p><p class="MsoNormal"> Mike said, no, that's not what we're doing<u></u><u></u></p><p class="MsoNormal"> Tim said that Presentation Exchange has paths to say where claims should to go<u></u><u></u></p><p class="MsoNormal"> <a href="https://identity.foundation/presentation-exchange/" target="_blank">https://identity.foundation/presentation-exchange/</a><u></u><u></u></p><p class="MsoNormal"> Tim said that that some use cases will use one or the other<u></u><u></u></p><p class="MsoNormal"> Kristina said she views these objects as claims at the same level of things like e-mail<u></u><u></u></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<u></u><u></u></p><p class="MsoNormal"> He needs to know the format that the claim will be returned in<u></u><u></u></p><p class="MsoNormal"> Tom reports that Mobile Driver's Licenses will be in ISO 18013-5 format - not JWTs or VCs<u></u><u></u></p><p class="MsoNormal"> John said that there are already four JWT claims formats - JSON, Normal JWT, Aggregated, and Distributed<u></u><u></u></p><p class="MsoNormal"> George wants there to be metadata about claims<u></u><u></u></p><p class="MsoNormal"> Mike said that Edmund's Claims Aggregation draft does enable claims to be requested in different structures<u></u><u></u></p><p class="MsoNormal"> <a href="https://bitbucket.org/openid/connect/src/master/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.md" target="_blank">https://bitbucket.org/openid/connect/src/master/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.md</a><u></u><u></u></p><p class="MsoNormal"> Oliver said that registering a small set of claims seems like a next step<u></u><u></u></p><p class="MsoNormal"> George wants to be able to request claims in particular formats, and with particular groupings<u></u><u></u></p><p class="MsoNormal"> That means that would have to work on richer claims requests syntax<u></u><u></u></p><p class="MsoNormal"> Mike said that he's trying to first solve the simple cases<u></u><u></u></p><p class="MsoNormal"> George said that this doesn't preclude more complicated cases<u></u><u></u></p><p class="MsoNormal"> Mike said he plans to write the tiny spec and explicitly say what it's not doing<u></u><u></u></p><p class="MsoNormal"> Tom said that you can't ask all Claims Providers to support VC formats<u></u><u></u></p><p class="MsoNormal"> Tom said that he might also write up a parallel spec for generic JOSE claims<u></u><u></u></p><p class="MsoNormal"> John said that we already have that: aggregated and distributed claims<u></u><u></u></p><p class="MsoNormal"> Tom wants to try to remove things from front-end processing<u></u><u></u></p><p class="MsoNormal"> John asks whether we want an external dictionary for VCs like we have for aggregated and distributed claims<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Browser Special Call Report<u></u><u></u></p><p class="MsoNormal"> We ran out of time for this<u></u><u></u></p><p class="MsoNormal"> Tim did send notes from the call to the list<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"> We ran out of time for this<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 regular Connect call is on Monday, April 12th, 2021 at 4pm 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>