[Openid-specs-ab] SIOP special topic call agenda (2021-08-05)

Kristina Yasuda Kristina.Yasuda at microsoft.com
Thu Aug 12 04:53:53 UTC 2021 

(I meant "notes" in the subject line..)
________________________________
From: Kristina Yasuda <Kristina.Yasuda at microsoft.com>
Sent: Wednesday, August 11, 2021 21:52
To: openid-specs-ab at lists.openid.net <openid-specs-ab at lists.openid.net>
Subject: SIOP special topic call agenda (2021-08-05)

Justin Richer
Oliver Terbu
Dmitri Zagidulin
Adam Lemmon
Anthony Nadalin
David Waite
Stephane Durand
John Bradley
Alex Nennker
Bjorn Hjelm
Pamela Dingle
Kristina Yasuda


- IPR reminder

- Introductions/re-introductions

- Agenda bashing/adoption

- Events/External orgs

     - DIF Presentation Exchange/OIDF WG update: https://github.com/decentralized-identity/presentation-exchange/issues

   ​- Main issues discussed are making presentation_defintion.id and presentation_submission optional; and how to communicate input_descriptor.id in the OIDC4VP response


- PRs

  *   SIOP V2 introduction and use-cases: https://bitbucket.org/openid/connect/pull-requests/41
     *   Agreed in spirit, editorial comments made
  *   Cross-device SIOP: https://bitbucket.org/openid/connect/pull-requests/33<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fpull-requests%2F33&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C0e97c31cf7894a31be4508d950d34339%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629690780989592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Udb7XR5xVu18teMuq16%2FoLupOlijO5NlWL%2Fe%2Fd8HAnc%3D&reserved=0>
     *   Agreed to merge as a starting point, need to confirm with Mike


- Issues

  *   SIOP V2
     *   Client_id in SIOP V2 https://bitbucket.org/openid/connect/issues/1272/client-identifier-in-siop-when-the-dids
        *   Dmitri, Oliver agreed with the proposal in the PR comment to re-use client_id to allow SIOP to verify the signed request
        *   Justin advised WG to define error conditions that everybody is expected to test for, if WG were to rely on the resolvable URI. Cases such as valid URI but cannot fetch it, URI not resolvable, not a URI but can be resolved. This would help avoid creating holes in security expectations and increase interoperability. Should also have a way to differentiate SIOP-based log-in.
        *   John pointed out that in SIOP V1, client_id had to match redirect_uri (was left unspecified)
        *   DW pointed out that some of this should be defined by OpenID Federation as part of its automatic registration: https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.9.1
        *
        *
     *   Security Considerations: https://bitbucket.org/openid/connect/issues/1269/add-security-considerations-for-cross<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1269%2Fadd-security-considerations-for-cross&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C0e97c31cf7894a31be4508d950d34339%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629690781019460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=okTAjch1DqHOvE3Su34gY%2FeU1sUryxrvS7FcBXlw%2FOA%3D&reserved=0>
        *   Stephane said that cross-device SIOP security considerations are out the reach of OIDC because they would involve external protocols, for example Kiosk use-case assumes physical presence of a user.
        *   John agreed, but said that we need to be clear that there are secure and insecure ways of using those external protocols with SIOP, not to degrade people's confidence in SIOP.
           *   rather than distinguishing the use-cases based on where the RP is - kiosk or a browser - it could be separated based on the trust level: 1/ trust the RP completely (implicit authentication); 2/ actual authentication where you have an account with an online service.
        *   Stephane pointed out that the trust framework can only vouch for a class of SIOP, not specific instance.
        *   John questioned whether SIOP itself "authenticates" to the kiosk - authentication happen between SIOP on the device and the backend service, how the user gets a transitive property of the kiosk letting the user do something (ie establish an account) is outside SIOP.
        *   We agreed that there are two systems - 1/between SIOP and backend; and 2/user and the kiosk, and that we don't really have ways to authenticate the latter securely. So it is not guaranteed that the user in front of the kiosk is the owner of the credential presented.
        *   John suggested that to ensure that some transitive authentication is needed. With FIDO, it will look like: make a resident credential with the backend in the browser on your phone, use CABLE over BLE or local NW to do FIDO authentication from your phone through the terminal to authenticate you in that other session.
           *   Or in the presented credential contains biometric data, kiosk can use local biometrics to scan your face or biometrics to match with the data in the credential
        *   We agreed to include these warnings related to the Kiosk use-case in SIOP security considerations.

     *   successful client registration response: https://bitbucket.org/openid/connect/issues/1267/successful-client-registration-response<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1267%2Fsuccessful-client-registration-response&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C0e97c31cf7894a31be4508d950d34339%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629690781009503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZkaYOno%2Bf4Rj8H5TKJ0sdi21DJ63%2BHLCwjqcAjdYbWs%3D&reserved=0>
        *   John will take a look
  *   OIDC4VP
     *   input_descriptor.id: https://bitbucket.org/openid/connect/issues/1264/include-input_descriptor-id-in-oidc4vp<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1264%2Finclude-input_descriptor-id-in-oidc4vp&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C0e97c31cf7894a31be4508d950d34339%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629690780999546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MSBJBBQ8kf%2FiODK9S5D5ApbP01PrZmx7TY3ACzEFNdI%3D&reserved=0>
        *   No one on the call was opposed to using input_descriptor.id as a way to differentiate VCs included in the response - the syntax how to pass these IDs in OIDC4VP without presentation_submission needs to be worked out
     *   Binding btw VC and VP: https://bitbucket.org/openid/connect/issues/1253/threat-analysis-for-binding-between-vc-and<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1253%2Fthreat-analysis-for-binding-between-vc-and&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C0e97c31cf7894a31be4508d950d34339%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629690781009503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NvQXwWhruS6FXXXqiB%2FEt2Fxdu93XxHdt13zaZIb7hQ%3D&reserved=0>
        *   vc-data-model specification does not require VC-VP binding to the same subject/SIOP holder
        *   we discussed if there are use-cases that 1/ absolutely require VC-VP binding, or 2/ would be blocked if such binding will be mandatory
        *   Dmitri suggested that sounds like current use-cases can be covered without mandating such binding
        *   user do not manage their own keys


Best,

Kristina





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

More information about the Openid-specs-ab mailing list