[Openid-specs-ab] SIOP special topic call minutes (2021-05-04)

Oliver Terbu o.terbu at gmail.com
Wed May 5 08:10:43 UTC 2021

Dear all,

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.

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.

Looking forward to refine the draft specification.

Below are the meeting minutes (thanks to Adam Lemmon for taking notes):

Oliver Terbu
David Waite
Dmitri Zagidulin
Torsten  Lodderstedt
Jeremie Miller
Adam Lemmon
Edmund Jay
Brian Campbell
John Bradley
Tobias Looker


Focus of the meeting is to review the recommendation of the W3C Verifiable
Credential objects draft

Goal is to recommend the draf to the Connect working group

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

May also be used for issuance, aiming to aligning with Credential Provider

IIW 3 options were outlined and there was no clear winner, narrowed to 2

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

Decided to only use VPs to wraps VCs and not allow VCs to be presented

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

… Began reviewing the current draft

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

We want to support both common proof formats, JWTs and LD proofs and
various signature schemes. JSON and JSON-LD encoding support desired.

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.

Examples of vp_jwts and vp_ldps, again aligning these with DIF PE

Also JWT parameters extension params, verifiable_presentation is the new
claim that serves as the container for the vp

Other option is the new artifact vp_token which serves as the container

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

Can request a vp based on the type of the credential and can specify
specific claims within that type, down scoping / selective disclosure

Examples of authorization code flow, implicit flow

Any objections from the group to raising this as a work item to the connect
working group?  No major push back

AL: Interested in further review of the credential request syntax

DZ: defining the type, if an array what is the logic on the query side? AND
or OR?

Torsten: this is underspecified now and not quite clear when multiple

DZ: possible to scope down to specific issuer or holder identifier

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

Jeremie: in support of adopting this work item then can provide feedback
once adopted

OT: great that is objective here to get this under OIDF to begin refinement
once document is under OIDF IPR etc

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

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

OT: Next steps to send out current draft to working group to adopt this
draft and can work towards a more robust spec.

John: no notification requirement, bring the draft forward as ready

Torsten: suggest to post to the list and ask it be on the agenda for
Thursday Atlantic call

OT: any other issues to discuss?

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.

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

OT: IANA registration of credential formats?

Tobias: suggested w3c_vc_ldp, w3c_vc_jwt

Torsten: these should fall in the issuance draft not here in the
presentation document

Tobias: would like to see both request syntax for credential issuance and
request for credential presentation to be aligned

Torsten: agree to align the mechanisms, main difference is selective

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

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.

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?

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.

OT: Agreed. Should we make sure this draft support the issuance use cases?

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

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

OT: May not be backwards compatible now.

Jeremie: can this be done with metadata..?  If the provider metadata said
which types it supported and provided different locations for it

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

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

OT: using DIF PE for request format?

Jeremie: to consolidate from 3 different presentation exchange specs; vc
http api, PE and WACI

OT: supportive of metadata approach

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210505/4d4a4e1b/attachment-0001.html>

More information about the Openid-specs-ab mailing list