SIOP Chooser

Issue #1212 resolved
Jeremie Miller created an issue

Following up from the thread in issue #1210 about a practical discovery flow for SIOP, and a subsequent discussion on the last SIOP special topics call.

This is a rough draft of a proposal that outlines how discovery can be accomplished today using a shared site and universal links as an alternative to the openid: URL scheme.

https://hackmd.io/@quartzjer/SIOP_Discovery_Trust_Framework

Next Step: If there’s interest, develop into a more complete implementation guide.

Comments (44)

  1. Tom Jones

    The meeting suggestion was that this might be handled by a sector specific trust registry. My suggestion would then be that the links on the RP be of the trust registries acceptable to the RP. The user would select one (perhaps the only one) and then the process would commence. I will examine healthcare soon.

  2. Tom Jones

    just capturing interesting comments from meeting

    Anthony Nadalin to Everyone. How do you know it's a secure site (ie that is not just some site controlled by the RP)

    Justin R = how to we convince RPs to trust this method (ie - how would this be better that google apple & facebook as IDP)

  3. Jeremie Miller reporter

    I’ve updated the draft at the link in the description to focus it on a solution for use within a trust framework, consistent with the most recent discussions and the last SIOP call.

    I’m also suggesting that a next step is logically a more complete implementation guide, there is nothing here that would constitute a standard.

    As far as influence on SIOP, each trust framework adopting this proposed solution should be allowed to use their shared site as the issuer and a native-linking path on that site as the authorization_endpoint value for the discovery metadata. The iss value on any resulting tokens should match the same shared site URL for verification within that specific trust framework.

  4. Kristina Yasuda

    Due to the inability to do openid connect discovery, authorization_endpoint is currently a static value and because SIOP req included in QR code or deep link usually already starts with openid:, it is hard to negotiate authorization_endpoint value by including it in registration/registration_uri parameter with RP metadata inside SIOP req like subject_identifier_types_supported for example.

    When authorization_endpoint is a URL to the shared site, that URL would be embedded in the QR code / link that SIOP holder would scan? I wonder if there is a way for SIOP to be able to support both custom schema and be part of a trust framework with a shared site.

  5. Tom Jones

    I think you are conflating three ideas that need to be separately evaluated.

    1. Siop wallet instantiation - which brings te wallet into view by the user. There are two scenarios here: (1) the user starts in the wallet (typical in most DIF scenarios) and (2) the user starts in the browser (typical in the real world.)
    2. SIOP wallet discovery - only exists in case 2 above.
    3. SIOP wallet communications (1) the user scans data in some way. (2) all comms is “front channel” in a SIOP sense that means the user takes no action other than consent. (that needs its own issue, I will create.)

  6. Tom Jones

    At the current time i would suggest moving this fwd as an implementation guide. It may happen that we need new specs, that that is not yet clear.

    I suggest we pick a goal like “Allow the user choice in which idententifier to use during registration with a new site.

    Second goal: “Maintain a list of prior user choices and indicate this in user choice, or allow user to pick a feature like ‘Use Always.’ “

  7. Tom Jones

    As to Kristina’s question about where this is available off-line. This is an implementation detail to be left to the developer.

  8. Michael Jones

    As discussed on the 29-Mar-21 OpenID Call, we agreed to call the process of choosing a provider to use “choosiing” - not “discovery”. In OpenID Connect, “discovery” is the process of retrieving metadata about the provider.

  9. Stephane Durand

    About solving the discovery through participation in a Trust Framework, is it fine to express a requirement on a technical implementation that is resolved through the context it will be used in?

    With SIOP, when used with VC / VP in particular, I was under the impression that one could implement a wallet that doesn’t need to have any relationship with a Trust Framework (the Issuer would convey its relationship to the TF in the VC, the holder use the VC to build the VP, which would maintain this relationship, and the verifier could in the end consume the VP as something related to the Issuer(s) Trust Framework(s) and figure how that relates to the Trust Framework(s) that are relevant to it).

    Another concern I have is that universal links are but implementations of selected mobile platforms and the proposition is inherently relying on them. If there is a change in theses implementation, the SIOP discovery become obsolete. In that sense, the custom openid: scheme was a better approach in my opinion, as long as the foundation “takes ownership” of it and specify how this scheme must be handled (and mobile platform owners implement it 🙂 )

    Now, I actually wouldn’t propose a different alternative than what is in the PR, but I see it as the best practical approach available, not something satisfying enough to form requirement in a standard.

  10. Tom Jones

    I have not yet seen any issue for the chooser that would fit within the scope of siop. If someone has a siop issue that would be impacted by the chooser, i would like to hear it.

  11. Kristina Yasuda

    I completely agree with you, Stephane. And I am also unsure if it is the best thing to mention trust framework in technical specification.

    I see it as the best practical approach available, not something satisfying enough to form requirement in a standard

    The way custom openid: scheme functions in both iOS and Android does not allow users to choose the app they want to use as SIOP, and universal links have its equivalents in any mobile platform. So custom schema does not really work even if foundation takes ownership of it.

    I would encourage to take a look at SIOP chooser [demo](https://drive.google.com/file/d/1PPt4uYuWncaKgq3_So8CpWTp6pYvC0ps/view?usp=sharing) and read the notes that led to demo: [Openid-specs-ab] [Demo link] Re: SIOP Special Call Notes 16-March-21

    We could simply say universal links SHALL be used for SIOP invocation, and explain how to discover a universal link (using TF, etc) in a non-normative implementation guide.

  12. Kristina Yasuda

    I was under the impression that one could implement a wallet that doesn’t need to have any relationship with a Trust Framework

    The WG discussion has been - RP does not know which instance of SIOP it is talking to each time, so there is no way to RP to pre-establish trust with SIOP (in OIDC discovery-registration way), but RP may know it is talking to one SIOP instance that belongs to a larger group/set that RP trusts, and one way to call that group/set has been trust framework.

    It’s not so much about trust in VC/VP provided by SIOP, but in SIOP itself.

  13. Stephane Durand

    Thank you for the links to notes and video (for web to app, it’s pretty much in line with what we experimented too; we didn’t investigate app to app as far as David presented)

    It’s not so much about trust in VC/VP provided by SIOP, but in SIOP itself.

    Yes and what I’m questioning is the need for the RP to have trust in the SIOP instance (I hear the concern about a malicious SIOP being used to fish the user’s data, but is that the RP’s concern? Is that something SIOP should feel responsible for?)
    As a comparison, if I submit a subscription application to a service provider, paper way with my supporting id-related documents enclosed in a mail, will the service provider care about who’s delivered the mail? Would he reject my application because I used a disreputable mailer? Here, I see that the SIOP instance may have a role that doesn’t go further than the mailing service.

    The way custom openid: scheme functions in both iOS and Android does not allow …

    This is the situation now, and openid: is treated as a ‘custom’ scheme whose handling is completely up to the application. But if there was a specification attached to it that lays some basic rules for application selection, would the platform implementers follow it and rather than just passing the request along implement a chooser step in the middle? I saw references to Apple and Google in the notes you shared but I didn’t see if they expressed a position on this question.

    For me, this is the most appropriate way to solve the discovery, but it requires the cooperation of the platform owners. Seeing that you are not taking this route, I suppose you have evaluated that such cooperation is not a given.

  14. Kristina Yasuda

    Have you experimented with web to app in a SIOP-like scenario? Was that on the same device?

    I agree that with mobile platform owners' cooperation, custom schema would have been the ideal solution, and you are right that we have not seen that cooperation - even in the mDL group. Most recent discussion is documented in [Openid-specs-ab] SIOP special topic call notes (2021-06-29)

    Regarding trust, there has been a similar conversation in this thread: [Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review

    But if there was a specification attached to it that lays some basic rules for application selection, would the platform implementers follow it … ?

    Sorry if I misread, are you suggesting there is a way for us to specify user-wallet-selection without platformers' cooperation? If so, would love to explore.

    Regarding trust, RP might not need to “trust“ SIOP, but it still needs to know how to invoke SIOP - so I think we are talking about few parties cooperating to host a shared website that could enable user-choice of the wallet (potentially via universal links)? because each individual SIOP cannot host such website. maybe “SIOP group” is a better term than a “trust framework”.

  15. Stephane Durand

    Our experimentations were on same device and the goal was to qualify/understand/feel UX-wise, how universal links worked. It was about a year ago and overall we were satisfied with the results.

    Sorry if I misread, are you suggesting there is a way for us to specify user-wallet-selection without platformers' cooperation? If so, would love to explore.

    Sorry, no magic wand here 🙂. I don’t really see a way to do without cooperation (ultimately, they are the one in position to know what SIOP apps are present on their platform and make it somehow available to support a chooser UX); I would just be counting on the “soft pressure” of having a standard to be compliant with to “buy” their cooperation.

    On the trust topic, I see there’s a dedicated issue #1255 "trust in self-issued identifiers" that has been brought up. I’ll share there if something worthwhile cross my mind.

  16. Jeremie Miller reporter

    Thank you Stephane for the great discussion!

    The intent of the chooser work is to be a collection of best-practices versus a standard. Documenting a technique available on most platforms that supports user choice versus a relying party hard-coded choice. Of course, with the tradeoff of requiring app-platform-specific metadata and a common site that a relying party can trust to result in a positive user experience. These are not insignificant requirements and definitely not something that can be baked into a standard.

    My hope is by highlighting that it is possible using available functionality, we might then be able to have productive conversations with app platforms on what a standards can do to help create a common solution.

    While that could take the form of a special/dedicated protocol handler, it would need to carry enough syntax for the platforms to present a good experience taking the user to an app that can fulfill the request. This can easily become the full syntax of DIFs Presentation Exchange.

    The closest analogy on platforms for that experience is the share sheets or sharing selectors that customize the available list of apps/actions based on what the user is requesting to share.

    The W3C has a Sharing API draft that is attempting to cover the common subset of that process, but the fidelity of the request is extremely limited to typical sharing scenarios.

    I anticipate the tension in this intersection between standards and platforms will be around the concept of a wallet where they will want to protect many of those flows directly (and likely employ local secure hardware only they have un-gated access to).

    There’s also clear demand for a large set of very rich use-cases with user-controlled holder/presenter software, and it may be challenging for platforms to uniformly support anything more than a simple request syntax.

    Perhaps there’s some middle ground, a stepping stone from the custom chooser suggested here that doesn’t require a type of trust framework or per-platform app links. I’ll definitely suggest such a path if I ever think of a viable one.

  17. Kristina Yasuda

    Yes, I think we have agreed that ultimately SIOP chooser would be captures in an implementation guide or a BCP-kind of a document.

    Would there be any suggestions how SIOP V2 text in PR #25 could be updated to be less contrivertial and capture this discussion?

  18. Kristina Yasuda

    On 2021-07-8 call, we agreed to assign the issue to @Jeremie Miller and @David Waite for the Implementation guide/BCP-style document. (getting you the write rights so that I can assign the issue itself to you - does not allow me now)

    We also agreed that we want to find the right text in SIOP V2 draft that 1/ allow for the SIOP chooser kind of invocation that is a combination of existing technologies and 2/ does not favor OS wallets. Please make suggestions to the PR #25

  19. Tom Jones

    i am now starting to determine what sort of documents / metadata the RP can supply to the user siop chooser to get the best UX. Is that in scope of this discussion, or do we need a new issue?

  20. Jeremie Miller reporter

    @Tom Jones I think that hinges on if the docs/metadata are specific to a chooser, or are also relevant if the RP just presented a nascar-choice up front.

    If the latter then I would suggest a new issue, but if it’s metadata specifically to help the process of another party finding/matching the correct wallet then let’s discuss that here.

  21. Tom Jones

    Not sure i get the distinction. SIOP chooser and many other protocols that i am supporting are strongly dependant on the user trusting the ID of the web site (RP). Sooo - i have started a page to discuss several years ago - it is at this site https://tcwiki.azurewebsites.net/index.php?title=Trusted_Identifier

    Now perhaps the metadata discussion (use of Entity Statement) is the right place for that discussion, but i thought that was part of SIOP chooser, or has it moved off on its own issue now?

  22. Jeremie Miller reporter

    Ahh @Tom Jones yes I follow now, that metadata/discussion isn’t specific to the chooser best practices on this thread/issue.

    Is the trust metadata you’re thinking of best discussed on your #1255 issue for now?

  23. Tom Jones

    In my world the only code that absorbs the metadata is the chooser. Whether that is on the device or in the cloud is tbd.

  24. Oliver Terbu

    I didn’t mention WalletConnect as an option for us, just that other communities implemented a similar approach. You could try out a demo here: https://example.walletconnect.org/

    IMO, a SIOPv2 Chooser could be provided a trust framework URI that HTTP GETs you list of issuer URIs or OP configurations. The RP could then display a UX component that renders buttons with logo+link (e.g. universal link) for the particular SIOPv2 OPs (wallets). We already have language in the spec but we haven’t standardized the endpoint. Also note, openid:// is already optional.

  25. Kristina Yasuda

    at 2021-10-19 call, Tom reported that he, Jeremie and DW are working on an implementation guide and will contribute the text once they have it.

  26. David Chadwick

    I think the whole direction of this Picker is misguided because it assumes that users will be knowledgeable about their numerous identifiers and will want to manage them. I don't believe that users will want to choose identifiers or know anything about them. I believe that users are interested in their electronic credentials (the equivalent of today’s plastic cards) and the identities that go with these. Users typically don't care a jot about what identifier is being used to cryptographically link their identity attributes to an identifier: transient identifiers are the best at protecting the user’s privacy and the user won't have any idea what the identifier is in any particular transaction. So the user will not be choosing identifiers as this draft assumes.

  27. Tom Jones

    I believe that there is a great deal of truth in David’s assertions about human’s desire for multiple identifier. The sad fact is i have ~100 of them today in spite of my desires to have none (they are typically called user names and each has their own lexical requirements). Without the help of a p/w manager i would not even be on atlassian at all. There are now ~100 DID methods. RPs will never to interested in supporting so many. How then to manage a world with ~100 digital identifiers per person? Doc Searls proposed a VRM, perhaps that would be a better word for what we are about?

  28. David Chadwick

    The simple answer is to make the 1000s of digital identifiers transient!. The VC eco-system we have developed is based on identities and not on identifiers - conceptually we don't use DIDs or DLTs (although we use a variant of did:key simply to encode a transient public key that the user is unaware of). The only identifiers the user is aware of are ones that are also the connection endpoints for communication mechanisms i.e. telephone numbers, email addresses, URLs etc. Since the user no longer needs un/pws to access resources when VCs are being used, then the need for these identifiers diminishes. If didcom becomes a ubiquitous communications mechanism between people, then these DIDs can be added to VCs in the same way as telephone numbers are currently done. I would only need to store 1 DID for you, which is the identifier I use to make a didcom connection to you. But of course we are proposing that people and systems use OIDC for communicating and not didcom, so I don't see didcom taking over any time soon. When I asked some didcom proponents why they thought S/MIME had failed to become ubiquitously adopted as the secure message passing infrastructure they did not know. If they don't know why S/MIME failed then they could repeat the same mistakes with didcom.

  29. Tom Jones

    In general that seems ok, BUT the RP will in general have more than one link for authentication and each would have its on URI which could be expressed as a QR code.

  30. David Chadwick

    Interestingly the Condatis approach is very similar to what I proposed for obtaining a presentation exchange in the syntax that the wallet supports 🙂

  31. David Waite

    Since the specification already supports invocation via custom URI or AppLink/Universal Link/registered HTTPS URI and by QR code, this seems better served by other informative text. Myself and perhaps Jeremie will work on a blog post describing the different mechanisms available and their trade-offs.

  32. Log in to comment