1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect

Wiki

Clone wiki

connect / 2021-03-16

View History
  • Adam Lemmon
  • Alen Horvat
  • Oliver Terbu
  • Tom Jones
  • Torsten Lodderstedt
  • Tim Cappalli
  • David Waite
  • Vittorio Bertocci
  • Jeremie Miller
  • Balazs Nemeti (DIF)
  • Erik Zvaigzne (Convergence tech)
  • Anthony Nadalin
  • Justin Richer
  • Kaliya Young

  • Kristina Yasuda

  • regrets: Mike, John, Nat

  • Introductions: Balazs, works at DIF

The time of the calls are 3pm PDT from this week.

Agenda: Issue Discussion #1212 Universal URL based discovery for SIOP

Overview of the proposal/initial Q&A

  • Jeremie gave overview of a proposal. A practical approach that tackles user experience issue with openid:// with what is available today.
  • Two aspects to the proposal: 1/letting the user choose the application; 2/handling multiple apps.
  • 1st aspect: RP wants to provide a user a choice of which app they might use SIOP with: can be mobile app or PWA. To prevent a NASCAR screen, it can be a discovery endpoint that provides linking into an app/PWA a user chose to install (universal links)
  • RP links to a URL of the shared site that contains metadata of the identifiers for all of the applications that can satisfy that request. If the user have chosen one, it will be automatically launched. If not, the user will be displayed with the option of available apps/PWAs
  • Tom: This can potentially be a very long list (on the shared site)?
  • Jeremie: Kristina and Pam suggested that this solution is best applied within a trust framework that RP belongs to.
  • Tom volunteered to provide such trust framework for the healthcare.
  • Alen: Two questions: 1. this can be a single point of failure. 2. Who would be responsible for paying and managing all the traffic.
  • Jeremie: this site will handle only the request. and if the user has an app installed natively, the site does not even get a request and. very little traffic unless user does not have an app and needs to discover.

Demo

  • [demo by David]
  • [Demo 1] David showed a screen with Apple app metadata cashed by Apple that indicates which apps are able to take control of the authorize path on this particular server.
  • David showed a not very helpful error screen that using openid:// option gives if user does not have a wallet installed. potential attack surface for fishing if a malicious app gets invoked first.
  • With universal links, if no app installed, user gets a list of potential applications and how to use them (including PWAs)
  • David installed an app real time. Now when user clicks a log-in link at the RP website, user is taken directly into a native application, authentication is performed and user is taken back to the RP.
  • (going between web-based flow and Native app flow using universal links instead of custom URL schemes)
  • openid:// does not let you choose which app to open. In this proposal, there is a predictable behavior, but it is a prioritized list.
  • [Demo 2] brewery app asking for the proof of age. User is presented with a screen with an option to install an app or use already installed State Identity Card. Uses Share Sheet functionality, based on the metadata that applications have at publication time about what kind of files they can deal with.
  • proof of age got shared right away because user has consented through the OS mechanism
  • for proof of age, passport and state id apps were options, but for shipping address, only state id app depending on the claims supported.
  • presentation exchange not used.
  • the app does not know which RP requested the address.
  • Kristina is looking for a way to share the recording of the demo publicly.

Discussion

  • Share Sheets
  • Oliver: How do you find the sharesheet provider? on iOS, Android, Windows, native versions of sharesheet capability exists. On Mac could be limiting, but can use.

  • David: Have talked to Apple and this proposal uses more features than usual apps, but is not against any rules. Share Sheet functionality is important because app store (and probably users) will reject any app that require another particular app (App A using only App B for authenticaiton for example). Have been working on app-to-app scenario for a while.

  • (Comments in chat how this would work reliably today, but OS vendors, Browsers could change things anytime without prior notice)

  • Tim: Apple and Google's participation is required. We need a broker mechanism at the OS level. OIDF level engagement is needed.
  • Jeremie: yes, the motivation of this work is to build something demonstrable, show that this is workable using the native capability, but not ideal, and ncourage OS vendor's participation to improve.
  • DW: privacy centric browsers, not very keen to rely on several large social networks should be interested in this new scenarios and enabling users to bring their own identity. Apple and Google would want to be on the broker list if they want to broker identity.
  • Tim: Apple and Google do not want you to bring your identity. (responding to a comment in chat that Apple and Google are working on vaccination credentials) there is a fundamental difference between gaining access to an app and passing information securely attested information.
  • Kristina: identifying use-cases would be very important

  • Justin: the most important thing is to get RPs to accept this. It was the case with OpenID Connect too. This has to be part of the conversation here.

  • Jeremie: opportunity is that discussion is shifting toward credentials which is different from authenticating and identifying yourself. and Google and Apple are not sources of those credentials.

  • DW: Does not see VC used for strong authentication, but looks at them as strongly attested attributes used for account recovery, or the link secret used to generate stable pseudonyms. how do I know DIDAuth is string enough? WebAuthn is strong enough, but it falls flat in recovery. Using strongly attested credentials tied not to the HW, but to the account for example could be used for the recovery.

  • Alen: Two questions. 1/ interop btw issuers and RPs. How does RP know how to validate credential from the issuer? 2/ what if RP accepts credentials only from the certified wallets and user has a needed credential in a non-certified wallet. Can I move a credential from one wallet to another?

  • DW: req can be richer, list of wallets can be filtered, to leave only those that can handle credentials requested by RP. (schema would have to be pre-agreed btw the RP and issuer) You will web-based fallback option - if a user does not have a credential RP wants, it can download a suitable wallet and get the credential.

  • Both the domain has to say they want the app and hte app has to say they want to support universal links from the domain

  • Balazs encouraged participants to review the charter of Wallet security WG in DIF that

  • Information for Wallet Security WG in DIF. Members are encouraged to comment on the charter.

  • Jeremie said he would update the issue with today's feedback.

Updated