Wiki

SIOP Special Call Notes 02-March-21

Albert Solana
Justin Richer
Vittorio Bertocci
Anthony Nadalin
Tom Jones
David Waite
Oliver Terbu
Tim Cappali
Jeremie Miller
Adam Lemmon
Kaliya Young
Edmund Jay
Markus Sabadello
Kristina Yasuda

Regrets: Mike Jones

IPR Agreement
- As the SIOP special calls are part the AB/Connect Working Group, anyone wishing to participate and contribute need to submit a contribution agreement: https://openid.net/intellectual-property/. The agreement signed between DIF and OIDF doesn't extend to their member's IPR.
Update
- New WG in DIF "Wallet Security" is starting (charter is being drafted) which discusses trust into the wallet is in-scope. Tom said we should monitor the progress in that group to have synergy and avoid overlapping scope with this group.
Action items
- Write up a more concrete proposal on the discovery and present a prototype at the next call (Jeremie and DW)
- Define success criteria for the discovery - number of SIOP SW installed, etc. (Tom and Tim)
New issues
Value of iss = self-issued.me (~~#1208~~)
- Questions: how to communicate the information about the SIOP SW provider and what is the rationale to use self-issued.me
- What is the rationale behind using self-issued.me as iss value?
  - Oliver: it was used as a source of static OIDC configuration because SIOP does not have a service endpoint. Questions why self-issued.me is needed.
  - DW: selfissued.me was not meant to be hit. Original limitations of SIOP when it was created was that only way to invoke a native app from a website was a custom url scheme. No good IPC channel between them, so redirect was chose.
  - Justin: goal of using this discovery launch point for SIOP was that all device driven things are started the same way, without knowing what kind of device you are trying to get to. Another hard issue is that issuer identifier used throughout the protocol is based on the initial discovery. In SIOP it pretends to be HTTP when it actually isn't.
- Oliver: any other requirement that RP needs to know discovery endpoint upfront before the authorization request is sent? Why do we assume discovery information is static?
  - Tom: the first thing you need to know is what sort of request the user can accept.
  - DW: You can't control what is kicked off using custom URL scheme. Having individual URL for PWA that is universal link allows to use specific wallet. That means users have to select which particular wallet they want to use. No control over what OS vendors would reserve for authentication flows, and this is not a solvable problem, rather tradeoffs.
  - Tom: we could make a unified statement to the browsers what we need - solving the NASCAR problem
Discovery proposal alternative to openid://
- Jeremie: Best effort, not a perfect solution, leans heavily on the platforms. Using the set of APIs that iOS, Android and Windows provide to present the user with the selection from that is already installed
  - Three parts. First, some common website to publish app IDs as authorized apps to open links for a given path that all RPs will target with a new Discovery request.
  - Second, when user clicks that link, the platform will query that website to discover if there is a local app that will handle the request to that path, it will open app.
  - Third, using the platforms' built-in share sheets capability - OS will present a list of applications that can handle that data. Any supporting app registered to receive that path would ask the OS to present the list of application that can support handling that request.
- DW: analogy is a native app version of CHAPI. What we can do now is self-issued.me can have metadata file for platforms that says which issuer people can redirect to rather than openid://, native app on the list will get triggered. Applications from third party app stores would also be able to opt in to receive those requests. Share sheets also work with app-to-app.
Following discussion
- Tom: you have to give the user the choice of identifiers to use, not the choice of applications.
- Jeremie: each platform has its own limitations on what and how you display in share sheet interface.
- Tim: this is about presentation exchange btw RP and the OS
- Tom: Need to look at both solutions in the cloud and the device. User chooses which identity gets to use with which RP. Creating standard-compliant wallets - would be easier to get browsers' support.
- Tim: we need to define the success criteria. One or several wallets.
  - DW: agree. Is the user responsible for maintaining several wallets that may conflict? Need to take into the reality of dependency on the platforms.
- Oliver: Can return change the requirement iss=self-issued.me if this new discovery mechanism is adapted? To include DIDs in iss for example.
  - Justin: Restrictions on the issuer identifier matching come from the discovery specification in OIDC. if a new discovery mechanisms is used, you're not bound to those same rules. It is fundamental to OIDC and very deliberate that there are two different fields in OIDC - who is the user and who says so.
  - The two are tightly bound only in so much as a user account is tightly bound to the IdP that asserts that user account. You do not want to constrain self-issued identifiers by requiring somebody be identified by their device because that is potentially very bad privacy risk, allowing colluding RPs to share information about an individual user.
  - DW: issuer and user identities today would have a parallel to user and wallet iidentity attestations in the secure wallet space.
  - Tom: wallet identifier and wallet instance identifier should be distinguished.
Supporting LD-proof signed claims
- Question addressed: how to send back VP signed by LD-proofs
- Oliver: proposal of introducing a new artifact vp_token that would represent VCs signed using JWTs/LD-proofs. It would be wise to support LD-proofs to embrace SSI community and allow new ZKP schemes (BBS+) and other privacy preserving technology that DHS SVIP program actively supports. Vp_token is a cleaner approach that is better from extensibility (additional claims?). Question to the implementers if this is viable. https://hackmd.io/PZE3__bjT-e3NnjTGK7PHQ?view
  - Kristina: introducing a new scope is a protocol change, which has significant ramifications. There would be lots of questions to answer, like what triggers its addition (possibly use of a "claims" request?), what if there are multiple VPs, etc.
- Tony: I would oppose is vp_token is exactly the same as VP, because it may cause a problem processing. There is an issue of no approved algorithms or canonicalization methods for LD-proofs. ZKP work has been done with JWTs too.
- Tom: success of this spec should not be dependent on the success of DIDs and VPs. You can canonicalize the whole VC/VP by putting it into JOSE structure, expand the header section.
- Oliver: no one has proven that works.
- Tom: Based on the NIST spec, would be good to separate credential provider and the identity provider. Discussion on how much work RPs would have to do to accept LD-proofs - add support for the existing relevant libraries or getting this inside HSM to use for fundamental features.
Other issues
- Multiple subs (~~#1209~~): Did not have the time to cover
Call Schedule
- The next SIOP special topic call is in two weeks at the same time