# The Case for SIOP and Trust Frameworks

## Intro

OpenID Connect was designed to meet the needs of both social authentication providers and those who want to support Bring Your Own Identity, where the user may host or delegate their authentication process. In addition, it describes Self-Issued OpenID Providers (SIOP) as a way to have an OP-in-your-pocket, a provider which is not web-hosted but instead a piece of software running locally on a personal device.

Recent efforts have been focused on expanding the usefulness of SIOP by extending it beyond local authentication and self-asserted attributes. Such efforts aim to add the ability to provide claims about authentication and user attributes from third party issuers. This includes statements about external authentication systems (such as DID-backed authentication), aggregated JWT claims, and W3C verifiable presentations.

However, a relying party is limited in their ability to rely on these features when they are optional extensions. This inability to rely on the presence and presentation of features has both operational and user experience perspectives. The user also does not have guarantees that the software supporting SIOP is secure or acting in their best interest.

Here, we make the case that Trust Frameworks are an important tool in fixing operational, experience, and trust-related issues, and that trust frameworks can address these issues additively without compromising the original SIOP model.

## Background

With using a custom URL scheme for launching an authentication/credentials request, we have several limitations.

In terms of user experience, platforms may not support controlling which installed application is launched, or even make guarantees the launched application will be consistent. If there are no applications installed which can handle a URL scheme, the user may not get a meaningful error.

The ability for arbitrary applications to register support for such a scheme also creates phishing and other abuse possibilities.

App Links are an alternative where a website registers applications which may be launched for given HTTPS paths, and an App opts in to handling requests for said website. This functionality is also called Web App Links on Windows, and Universal Links on iOS.

App Links provide an ordered list of applications which can be launched instead of a web browser. The behavior of which of several applications is launched may be configurable on the platform, but is consistent across platforms based on priority ordering. Since the list of potential applications is controlled by the website itself, registration of arbitrary handlers is restricted by the platform[^1].

Finally, the ability to invoke via a HTTPS URL means that a sensible web-based fallback can be established. This could be used to inform the user about such things as: what is being attempted, to give the option to install a native application, or present one of several web-based alternatives.

## Trust Frameworks

The adaption of common metadata and content for multiple independent entities posits the creation of a trust framework for that group of entities. An issuer, holder, or verifier could participate across several trust frameworks for different requests. The trust framework can itself specify the technical and interoperability requirements. It can also dictate policy such as the consent process necessary for a holder to release information on a subject, and have restrictions on a verifier sharing said information with other parties.

The ability to specify such policies as metadata pushes dynamic negotiations of capabilities to static policy sets. In this way, the technical stack necessary for interoperability within a given trust framework can be substantially reduced.

## The Evolution of SIOP

The current Self-issued OpenID Provider functionality is limited in several regards:

- SIOP has a limited set of required features and open participation, as well as no established interoperability or evolution process
- Existing SIOP code may not have newer functionality which entities may require, such as portable identifiers or support for presentations
- Even in environments where the user is given a choice of SIOP apps, that choice is not filtered based on the request and the user may be left with a list where some or all of the options will always fail

This instead proposes that several of the features in SIOP can be broken out and made more generally available so that different trust frameworks can define their own alternatives. Part of this would be allowing these 'provider collectives' to use univeral links as an additional alternative to the custom URL scheme and to implement the alternative behaviors and policies described above.

Such collectives would be able specify technical (such as supported credential formats) and non-technical (such as privacy/consent) requirements. They can limit participation to only members which support the protocols and formats desired, which not only provides a more consistent and successful experience for the user but also allows some dynamic negotiation steps to be skipped entirely. They can define how to best deal with cases where there is no native application installed or multiple native applications installed.

Under such a proposal, SIOP changes from being the umbrella name for a set of technologies to being one definition of an existing open collective with very few limitations.

As universal links require both the the trust framework and the individual app to indicate trust[^1], it is appropriate for a 'closed' or 'permission-based' trust framework. The governance model controls certification and provides a technical means of providing evidence of certification. Such a certification process can also validate non-technical criteria, such as the process of prompting for and capturing user consent.

Likewise, use of a custom URL scheme is typically only controlled by the platform and not delegated to a decision by an external trust framework. This may still be appropriate for an 'open' or 'public' trust framework like the traditional SIOP system, where entities are expected to self-certify conformance.

[^1]: Android allows other apps to publish their ability to handle a web domain regardless of of an app link being declared on the website, but this functionality is being limited such that launching the app can only be done via user action or user settings configuration. A trust framework might additionally indicate certification via a cryptographic process (trust chain, trust mark, or acceptable list of externally generated attestations) to distinguish entities within a closed trust framework