<div dir="ltr">Dear all,<div><br></div><div>Thank you for participating in the SIOP special call. The major outcome of the meeting was that the SIOP Special Call group agreed that we recommend the current OIDC W3C VC Objects draft to be adopted by AB/C WG.</div><div><br></div><div>Next steps: I will send out the PDF to the AB/C mailing list and ask for official adoption. I hope AB/C will add this topic to the next AB/C (Atlantic) call this week.</div><div><br></div><div>Looking forward to refine the draft specification.</div><div><br></div><div>Below are the meeting minutes (thanks to Adam Lemmon for taking notes):</div><div><br></div><div>Oliver Terbu<br>David Waite<br>Dmitri Zagidulin<br>Torsten  Lodderstedt<br>Jeremie Miller<br>Adam Lemmon<br>Edmund Jay<br>Brian Campbell<br>John Bradley<br>Tobias Looker<br><br><br>OT:<br><br>Focus of the meeting is to review the recommendation of the W3C Verifiable Credential objects draft<br><br>Goal is to recommend the draf to the Connect working group<br><br>Purpose of the draft is to define standard way to include VPs in an OIDC response such as SIOP v2 but also other OIDC flows<br><br>May also be used for issuance, aiming to aligning with Credential Provider draft<br><br>IIW 3 options were outlined and there was no clear winner, narrowed to 2 options<br><br>Decided to move forward with both options; 1 is use id_token to include the vp and 2. Is a new artifact, vp_token.  Aggregated claims ruled out<br><br>Decided to only use VPs to wraps VCs and not allow VCs to be presented directly<br><br>Can recommend to the Connect working group to adopt the current draft, has received positive feedback from IIW and Connect working group thus far, wish to continue the work as an official draft under Connect working group<br><br>… Began reviewing the current draft<br><br>Some use cases are listed communicating utility of the extension, custodial SSI approach where provider would manage VCs on behalf of end users, directly from wallet to verifier<br><br>We want to support both common proof formats, JWTs and LD proofs and various signature schemes. JSON and JSON-LD encoding support desired.<br><br>Container introduced is the vp that contains a format property which defines what the format of the included vp is, using the same names as the DIF PE spec.<br><br>Examples of vp_jwts and vp_ldps, again aligning these with DIF PE<br><br>Also JWT parameters extension params, verifiable_presentation is the new claim that serves as the container for the vp<br><br>Other option is the new artifact vp_token which serves as the container<br><br>Examples of verifiable_presentation requests using the claims parameter that defines where to return the vp, either as a claim within the id_token or as the separate artifact vp_token<br><br>Can request a vp based on the type of the credential and can specify specific claims within that type, down scoping / selective disclosure<br><br>Examples of authorization code flow, implicit flow<br><br>Any objections from the group to raising this as a work item to the connect working group?  No major push back<br><br>AL: Interested in further review of the credential request syntax<br><br>DZ: defining the type, if an array what is the logic on the query side? AND or OR? <br><br>Torsten: this is underspecified now and not quite clear when multiple defined<br><br>DZ: possible to scope down to specific issuer or holder identifier<br><br>Torsten: not a ton of detail as yet to drill down into these features. Can leverage DIF PE exchange to support wider level of constraints<br><br>Jeremie: in support of adopting this work item then can provide feedback once adopted<br><br>OT: great that is objective here to get this under OIDF to begin refinement once document is under OIDF IPR etc<br><br>Torsten: claims parameter and vp token are representations that community hasn’t reached consensus yet on the best path forward… to learn through prototypes and discussions to align on one solution moving forward<br><br>Jeremie: concerns looking at the PE spec due to complexity it is taking and would be happy to see this spec remain simple and well aligned with OIDC<br><br>OT: Next steps to send out current draft to working group to adopt this draft and can work towards a more robust spec. <br><br>John: no notification requirement, bring the draft forward as ready<br><br>Torsten: suggest to post to the list and ask it be on the agenda for Thursday Atlantic call<br><br>OT: any other issues to discuss? <br><br>Jeremie: question on the naming on this document… seems to be adding a more generic container format for various other credential types not just W3C.. any reason this is specific to W3C or open to more wide support.<br><br>Tobias: Credential provider has taken an approach of abstracting the credential format as well, aiming to support beyond just W3C VCs style credentials. Agreed with Jeremie to allow extensible credential formats<br><br>OT: IANA registration of credential formats?<br><br>Tobias: suggested w3c_vc_ldp, w3c_vc_jwt<br><br>Torsten: these should fall in the issuance draft not here in the presentation document<br><br>Tobias: would like to see both request syntax for credential issuance and request for credential presentation to be aligned<br><br>Torsten: agree to align the mechanisms, main difference is selective disclosure<br><br>Tobias: credential is just grouping of claims… but may imply something broader ie driver’s license. Request to claims issuer vs to a holder you may wish to downscope the request so see the syntax as the same but RP to holder selective disclosure being more often <br><br>DW: credential types could be just media types application/* as we do with JWTs, need to understand space better to see what else we may need… format of claims need to be tracked then media types may not work.. If media types than may not want to be as specific as the above format values.<br><br>OT: current draft talks about VP exchange, can also use the container to send an issued credential to a holder, in that case both use cases would be supported on selective disclosure and issuance. How to ensure Credential Provider spec can be incorporated and that they can be aligned. Should that work also be included in the draft discussed today?<br><br>Tobias: latest thinking would align them as a single draft, using the same syntax for providing a credential as issuance and presentation. One requires binding to holder to indirectly present it thereafter. In essence they are providing a credential and same holds for presentation.  Everything else for how claims, credential types etc are very similar. In both cases a party is requesting claims from a provider about a party.<br><br>OT: Agreed. Should we make sure this draft support the issuance use cases?<br><br>Tobias: because OIDC has claim syntax, we want to evolve it as has been done with this draft and as we are doing with Credential Provider spec. We are better to focus on claims request syntax that doesn’t get too into the weeds of particular formats. Difference if you request binding (issuance) or just presentation of the VC with proof of control via VP<br><br>DZ: Would like to see switching off of claim names with the query format, this is the request for credentials with classic oidc format or with PE format, mime type the query itself<br><br>OT: May not be backwards compatible now.<br><br>Jeremie: can this be done with metadata..?  If the provider metadata said which types it supported and provided different locations for it<br><br>DZ: why to consider mime type on the query, can specify different predicate logic, ie. from this issuer or this holder, PE spec has one syntax of that filter, other specs have different ones on the query itself. Even if all want the same VCs back.  Question remains how to reconcile back to oidc spec.<br><br>Jeremie: was on the PEx call. Not yet diving into the specifics they are defining new PE flow to present VCs, forming that WG under the DIF. WACI PEx. <br><br>OT: using DIF PE for request format?<br><br>Jeremie: to consolidate from 3 different presentation exchange specs; vc http api, PE and WACI<br><br>OT: supportive of metadata approach<br><br>Torsten: keep simple to not hurt interop, requirements and use cases clear. In the spec written tries to be very explicit about requirements and what the problems are you want to solve and how you are going to solve them. <br><br>OT: next steps Oliver will send pdf to OIDF for adoption as recommendation from this group, then discuss on next call on Thursday and aim to have document on bitbucket<br></div><div><br></div></div>