[Openid-specs-ab] Notes SIOP call (2021-09-21)

[Kristina Yasuda]

Jeremie Miller
Michael Barrett
John Bradley
George Fletcher
Jeff Corrigan
Dmitri Zagidulin
Edmund Jay
David Waite
Mike Jones
Kristina Yasuda

Thank you for a very productive call!

- IPR reminder/recording

- Introductions/re-introductions

  *   Jeff Corrigan - AWS, Senior Solutions Architect Identity Specialist, has been involved with ISO mDL

- Agenda adopter

- Events/External orgs

  *   We discussed impact of Mozilla's objections to W3C DID-CORE on SIOP/OIDC4VP work. Kristina said that there is no impact because 1/ the direction we are taking with resolvable subject identifiers is general enough to allow non-DID methods for SIOP to prove control over the keys; 2/ Verifiable presentations do not require DIDs. Jeremie and Dmitri agreed.

- PRs

  *   https://bitbucket.org/openid/connect/pull-requests/50
     *   Jeremie reported that based on feedback at the Connect WG call and Brian Campbell, the new direction is to redefine the core primitives from PAR as a response flow as a separate specification instead of directly referencing PAR (https://datatracker.ietf.org/doc/html/rfc9126)
     *   John and George agreed this makes sense. On the surface the same idea as PAR, but exactly the opposite.
  *   https://bitbucket.org/openid/connect/pull-requests/45
     *   We discussed the need for a vp_hash as a mechanism to prevent a mismatch attack when attacker knows the nonce and the audience values
     *   John said that VC replacement with a malicious VC that's bound to an ID Token that is authenticating a user could be a legitimate attack if done before the first response, noting that is is hard but not an impossible attack
     *   when multiple VPs are returned, vp_hash can be a delimited concatenation of multiple vp_hashes.
  *   https://bitbucket.org/openid/connect/pull-requests/44
     *   We discussed that extentions to userInfo endpoint will be needed if VPs were to be returned from userInfo endpoint with repeated requests
     *   DW noted that crypto (usage of nonce) will be different because there's no request for presentation from the verifier as part of the userInfo endpoint. There are algorithms where holder needs to supply nonce to be able to check if returned value is correct. George agreed
     *   John noted that access token is not sufficient to generate a new VP

- Issues (https://bitbucket.org/openid/connect/issues?status=new&status=open&component=SIOP&component=Verifiable%20Presentation)

  *   https://bitbucket.org/openid/connect/issues/1208/siop-v2-dynamic-iss-claim-ref-required
     *   Kristina noted that iss=self-issued.me being the main mechanism to distinguish SIOP flow from other OpenID Connect flows, I believe we should keep this.
  *   https://bitbucket.org/openid/connect/issues/1259/redirect_uri-claims_supported
     *   It was suggested that it is ok to include redirect_uris in the registration block in the signed request when signing keys are pre-negotiated between RP and SIOP, and not obtained in the same signed request and unless these signing keys are not overwritten. in other cases, redirect_uris should not be included in a registration block.
  *   https://bitbucket.org/openid/connect/issues/1217/require-jar-in-siop-to-strongly-id-the
     *   DW said we need to confirm with OpenID Federation authors why the request for automatic client registration needs to be unique/one time use. Mike and John recommended to ask Roland
  *   https://bitbucket.org/openid/connect/issues/1332/is-sub_jwk-required-or-not-if-sub_type-is
     *   Editorial PR, assigned to Kristina
  *   https://bitbucket.org/openid/connect/issues/1027/write-a-self-issued-idp-si-idp-best
     *   Mike believes this has been overtaken by events
     *   WG to ask Nat at the next Connect WG call
  *   https://bitbucket.org/openid/connect/issues/1196/siop-credential-wallet-as-a-pwa
     *   Need to ask Kim Cameron
     *   Dmitri said that the main obstacle in SIOP v1 for PWA is the usage of custom URL schema for invocation, because of the poor support of it by the browsers. John suggested documenting that use-case with Federated Identity WG in W3C to get attention of the browsers. https://github.com/w3c/fedidcg
        *   Reference: what Google is proposing for Identity mediated by the browser: https://wicg.github.io/WebID/

     *   John noted that PWAs might need some sort of authentication and encryption that overlaps with WebAuthn. Dmitri agreed that having WebAuthn support for PWAs is very much needed.

     *   Dmitri shared the difficulty to identify is the difficulty that Solid's use of OpenID run into - trying to go around by creating ephemeral key pairs in local storage and using them as temporary RP ID, but it is a hack

     *   we also discussed caBLE

        *   caBLE is a way to pair a phone with a browser so that PF authenticator on your phone can be used as a roaming authenticator with your browser. crypto in the introduction is done by Bluetooth, but the actual communication is done over Websocket provided by the phone application.

        *   it is essentially a NW-based communication btw phone and the browser after a local Bluetooth pairing and exchange of crypto information

Best,

Kristina





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