[Openid-specs-ab] SIOP notes (2022-Mar-17) - Atlantic call @ 7AM PST/2PM UTC

[Kristina Yasuda]

Kenichi Nakamura
Jeremie Miller
Rolson Quadras
Joseph Heenan
Tim Cappalli
Torsten Lodderstedt
Jo Vercammen
David Waite
David Chadwick
Giuseppe De Marco
Brian Campbell
Mike Jones
Kristina Yasuda

- 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%7C85819e68816a46d7483008d9fcc62309%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637818751117142173%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=zol0YtG%2Buyus3B3buGg06mqCSqckOJXG0bEvPM2ms2E%3D&reserved=0>

  *   Marged PR #134 - oidc4vci: removing an option to submit a VP in Authorization Request [oidc4vci];

     *   Closes Issues #1443
     *   Issues #1450, #1444 will be resolved once PR on pre-authorized token will be merged

     *   Currently, there is only one option to present VP as an input to get a VC issued - Issuer initiating an ODIC4VP flow to the wallet after receiving Authorization Request from the wallet. Issue #1376 is warning us against that.
     *   PR #138 pre-authorized code opened after this call to allow an option to send VPs to the Issuer prior to starting an issuance process

  *   PR #136 - clarify holder binding; Issue #1453, #1452

     *   Edited to make a `proof` object containing both key material and a signature
     *   To explain other `proof` types, agreed to get examples from Tobias on BBS+ and David C. on JWK URI
     *   Agreed to merge after examples are added
     *   Need to continue discussing terminology "Holder"

  *   Merged PR #101 - presentation_definition_uri;

     *   Closes Issue #1440

  *   PR #137

     *   Kristina broke this PR into two separate PRs (PR #140) to address issues on user consent and mandatory/optional claims separately
- 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%7C85819e68816a46d7483008d9fcc62309%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637818751117142173%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2FptcC7czf%2F6pRnHRKNB8BTofB2OLMj0XzbrXiIfrd%2FQ%3D&reserved=0>

  *   #1460: Support for FIDO (WebAuthn)

     *   Tim clarified that FIDO/WebAuthn keys are tied to the origin and not the native application itself, hence they do not serve the purpose described in this issue of identifying "device".
     *   WG seems to agree that it is not recommended to use authentication protocol like FIDO/WebAuthn for other purposes such as described in this issue ("use of FIDO challenge and response tokens passed in another protocol, in order to authenticate the wallet app to the Issuer")
     *   DW pointed out that using WebAuthn could result in user being prompted to authenticate each time the issuer wants to recognize that device later in the flow

  *   #1454: defining a credential type

     *   David C. and Kristina spoke in favor of URIs as credential type and having a more flexible mechanism than a registry to manage types
     *   Need to flesh out details more, PR will be helpful

  *   #1461: Supporting HW attestations in the credential request when cryptographic binding is being used

     *   WG agrees with the need for such HW attestations
     *   Need to flesh out details more, PR will be helpful

Next call will also be the same time as this week - 7AM PST/2PM UTC



Best,

Kristina




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