[Openid-specs-ab] SIOP call notes (2022-Mar-31) - Atlantic call @ 7AM PST

[Kristina Yasuda]

David Chadwick
Vittorio Bertocci
Daniel Fett
Giuseppe De Marco
Joseph Heenan
Torsten Lodderstedt
Jo Vercammen
David Schudde
Rolson Quadras
David Waite
Tom Jones
John Bradley
Petteri Stenius
Mike Jones
Kristina Yasuda


- meeting recorded

- Introductions:
              - David Schudde from Yorba introduced himself: https://yorba.co. He can be reached at schmudde at yorba.co<mailto:schmudde at yorba.co>

- Agenda adopted

  *   Industry update

     *   W3C VC WG finalized charter for the vc-data-model-v2: Verifiable Credentials Working Group Charter (w3c.github.io)<https://w3c.github.io/vc-wg-charter/>

        *   If all goes smoothly, the work on it would start within the few months, once the charter gets approved

     *   ISO SC17 WG10 working on presentation of mDL over the Internet has asked about the stable version of SIOPv2 and OIDC4VP, since the latest technical specification from ISO mentions it

        *   WG agreed to work towards publishing Second Implementer's Drafts of SIOPv2/OIDC4VP with all the breaking changes from the First Implementer's Drafts before the publication of the ISO's specification, so that the document referenced by the ISO is very unlikely to have technical breaking changes before going to final
        *   Editors will start with triaging the issues to have a list of potential breaking changes that needs to be prioritized in the WG
        *   ISO SC17 WG10 agreed that SIOP features have "parity" with mdoc request-response that ISO WG has been working on (huge progress)



  *   Editors of the OIDC4VCI spec indicated that they would like to make as much progress as possible on the specification before IIW

- PRs https://bitbucket.org/openid/connect/pull-requests/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fpull-requests%2F&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C076de138a9434313d7df08da07b1c590%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637830758257768797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=NvwjmfI%2Fu8jgnKi%2FREuHrJnm0RjZmYT6F5I1XjaCxiY%3D&reserved=0>

  *   PR #138 - oidc4vci: pre-authorized code: https://bitbucket.org/openid/connect/pull-requests/138

     *   Torsten introduced the issue.
     *   Daniel F. pointed out the need to add new security considerations since anyone who can get hold of a QR code could get a VC issued

     *   Mix-Up attack, Brute Forcing attack on the PIN, Authorization code injection attack were mentioned

     *   David C. clarified if the PIN was one-time use. Currently it is intended to be one-time used, passed via a separate channel
     *   WG members are encouraged to review the PR, especially on the security aspect
     *   We agreed to discuss this PR during the next SIOP call, after people had more time to review it

  *   PR #136 - oidc4vci: clarify holder binding: https://bitbucket.org/openid/connect/pull-requests/136

     *   merged

     *   Issues #1453, #1452 resolved

  *   We did not cover more PRs, but people are encouraged to review. In particular,

     *   PR #145: [oidc4vci] Revises the approach to credential metadata publishing: https://bitbucket.org/openid/connect/pull-requests/145

        *   Related to issue #1466

     *   PR #142 oidc4vp: example with anoncreds: https://bitbucket.org/openid/connect/pull-requests/142
     *   PR #144 updating SIOP v2 definition: https://bitbucket.org/openid/connect/pull-requests/144
- Issues https://bitbucket.org/openid/connect/issues?status=new&status=open&component=SIOP&component=Verifiable%20Presentation&component=Credential%20Issuance<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%3Fstatus%3Dnew%26status%3Dopen%26component%3DSIOP%26component%3DVerifiable%2520Presentation%26component%3DCredential%2520Issuance&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C076de138a9434313d7df08da07b1c590%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637830758257768797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ccce9PXmdGPLv%2FssVmoUlIkXN%2FudMScnnEVJSuAegHQ%3D&reserved=0>

  *   #1467: DID resolver method for OIDC Federation (did:openid:!) wrt SIOP v2: https://bitbucket.org/openid/connect/issues/1467/did-resolver-method-for-oidc-federation

     *   There is a need to clarify what we would achieve by replacing http URL with DIDs as a mechanism to obtain Entity Statements in OpenID Federation
     *   WG members are encouraged to continue discussion in the Issue
     *   Probably better to classify this as Federation related issue

  *   #1470: SIOP Response without ID Token with only a VP Token: https://bitbucket.org/openid/connect/issues/1470/siop-response-with-vp_token-only

     *   Vittorio pointed out that without ID Token, this would not be OpenID Connect
     *   Torsten made a point that it will still be a protocol on top of OAuth, and if we want OAuth/OIDC based protocols to be used, they should be as simple as possible to be able to compete with other emerging protocols
     *   Rolson shared that as an implementer who started implementing SIOPv2/OIDC4VP already having VC/DID implementation, they got VP Token part straightforward, but still struggle with ID Token implementation
     *   John advised not to use `scope` parameter to indicate that there is no need for the OP to return an ID Token, so as to be respectful for the existing OP implementations. Probably use response_type, or response_mode. This would be especially relevant if we will expand definition of SIOP and allow self-issued ID Tokens to be sent using code flow.
     *   Torsten mentioned few use-cases where SIOP with code flow would make sense - cloud wallet, eIDAS, etc. https://bitbucket.org/openid/connect/issues/1399/siop-with-any-oidc-flow
     *   There was support in the chat towards using `response_type`
     *   We agreed to explore mechanisms to turn off a feature to return ID Tokens, also taking into account existing OIDC implementations, who might support self-signed ID Token features

  *   From the chat

     *   Tom Jones: "The PEMC is creating a set of requirement for any identifier that is send from a verifier to a wallet in order to assure the the user can make a valid conset to release data - would the SIOP be interested in such requirements? They would apply to SIOP and well as 18013-5 if adopted. My own take on this would be that any identifier contained in the requiest would be guaranteed (tbd) by the verifier to be a valid representation of the request. For example if square the request they would guarantee the identifier of the merchant in the request"
     *   Relevant URL?: https://kantarainitiative.org/groups/PImDL-work-group/



Next SIOP call is April 7th 8am PST.



Thank you!

Kristina




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220331/cf017c88/attachment.html>