SIOP V2: openid:// should not be required but an optional URI scheme

[Adam Lemmon]

Hi All

Disclaimer: A solution to wallet discovery is out of scope for this issue

It appears the same conclusion presented below was also reached here #1199 and some recent commentary here too #1207.

But as per last week’s SIOP V2 review it appeared that openid:// was still marked as required. Perhaps this is just a matter of the update still needing to be made to the document but we wanted to make sure this one was flagged for revision.

Currently section 2.1 of Self-Issued OpenID Provider V2, draft 01 states:

• Self-Issued OP MUST associate a custom schema openid:// with itself. Relying Party MUST call openid:// when sending a request to a Self-Issued OP.

Without diving into alternative solutions for discovery (being discussed elsewhere), for the scope of this issue we hope to simply reach consensus with the following statement:

• openid:// should not be required but noted as an optional URI scheme.

We present this as openid:// does not sufficiently account for the following scenarios:

1. Support for various deployment architectures such as PWAs or cloud servers, likely addressable behind https://
2. The holder has multiple wallets on a single device
3. The holder has multiple wallets across multiple devices

If others are also of this opinion than we’d be happy to collaborate on alternative language for this section.

Thanks!

[Tom Jones]

I guess i am missing something here. If you a putting a url in this field, why don’t you just use OIDC the way it is written?

[Adam Lemmon]

Thanks Tom and yes agreed, I believe that is the hope in aiming to not constrain this to just openid://.

To support existing OPs as well as SIOPs in varying deployment architectures.

Sorry just to clarify then Tom, are you agreeing that openid:// should be optional?

[Tom Jones]

To be clear - i am asking why you cannot use openID connect as it is written. It seems to work very well with URLs.

[Adam Lemmon]

Yes I agree with you Tom

This issue is simply trying to address the current language in the SIOP V2 document requiring RPs to use openid://

[Kristina Yasuda]

How would RP know which URI scheme to use to invoke a SIOP?

[Adam Lemmon]

Thanks Kristina, as noted above discovery is outside the scope of this issue

Many other conversations ongoing on discovery specifically elsewhere; CHAPI, Smart Credentials etc.

‌

[Kristina Yasuda]

Discovery is required for SIOP and any other OIDC flow. openid:// is current discovery mechanism, which has issues I agree, but we cannot make it optional without a solid better option.

[Tom Jones]

no - i am telling you to use openID connect as it currently exists. Unless there is some discovery step that you believe needs to be run prior to this user clicking on some button on the web site in which case you might need to use some feature of SIOP that has yet to be formulated.

[Adam Lemmon]

@Kristina - agreed that we need a suitable alternative that is not yet finalized and understand if you’re not comfortable updating the language in the document until that time. However, we wanted to ensure that the current language is not seen as having been agreed to or finalized. Happy if this sits here as blocked for now as we work on discovery solutions but at least remains as a reminder that this language is to be updated once an alternative is agreed upon.

@Tom - An excellent point and would completely agree with you! Refining the edges of “SIOP“ would likely be a worthwhile exercise too. I don’t see anything specific to SIOPs here either… and that is essentially our hope in the mentions above of support for other deployment architectures as well as existing OPs and SIOPs. Because I think the question for the RP is which OP to send the auth request to, not which SIOP to send the auth request to… just in some cases that OP may happen to be a SIOP, but nothing necessarily needs to change for that RP eh… just support for self signed responses etc?

[Tom Jones]

let’s not conflate deployment issues with protocol issues. An OP is an entity which is deployed, a siop is a spec for a protocol.

[Kristina Yasuda]

I think we should be careful when comparing SIOP with existing OPs. Capability of Self-Issued OP to enable end-users issue self-signed tokens is quite distinct in thinking from “existing” OPs.

From few conversations I had, it requires change in mindset for existing OPs to understand Self-Issued OPs, before we even talk about protocols or specs.

though after aligning on the concept, Self-Issued OP can be used to mean an entity which is deployed, too IMO.

[Kristina Yasuda]

is https:// the only URI scheme that can be used to invoke a PWA wallet?

[Jeremie Miller]

While I haven’t seen an obviously-best solution for discovery, I do think there’s an approach that can get us closer to the ideal for a significant number of use cases with some work. Those who are familiar with the Account Chooser effort will find some strong parallels with this proposal.

The alternative to protocol handlers that most major app platforms prefer is associating a website to a native app for automatically handling links. In iOS this is called Universal Links, on Android it’s App Links, and on Windows it’s Website to App Linking. All of them are extremely similar, publishing a .well-known/ JSON file that associates one or more apps to paths on the given website so that they will be handled natively if installed. If no apps are installed it is just a normal web link/page.

Another essential component to this proposal is the wide support for share sheets on Android, iOS, and even an advancing W3C proposal for browsers. This utility is the most native version of a discovery or chooser experience available. One app (or site) can provide some data and the platform will then present to the user a filtered list/sheet of apps or choices of how to handle that data.

So if we bring all three of these things together, a common website that is owned and managed by the OpenID Foundation (like Account Chooser) and publishes supporting apps in the appropriate json files to handle a common path on the site. And then in order to qualify to be included, each app is required to present a share sheet whenever it is called for an app link from the common website.

This results in a common website link with a customizable standard path that will open any supported app that is installed and immediately present a list of any installed apps that can handle the request (which the handling app may or may not be one of). If none are installed, the request will just be a web page served by the common website that presents the same list of apps that can be installed to handle it.

There will be some standardization effort involved to define the path and any request arguments that allow for the most granular filtering of potential matching apps to be shown in the share sheet. It would make sense to also have common open source code for each platform to handle the incoming links and present the share sheet correctly. Then there is also the management effort for the website, hosting, and validating registrations.

Overall I believe it’s as close to a great experience for users as could be built with what’s available, and possibly a pattern that could be re-used for similar discovery challenges in other contexts outside of SIOP.

[Tom Jones]

That is one solution worth creating. Another would be to require ALL SIOP to offer the user the choice of any wallet on the phone. In other words, require any openid:// wallet to be at least somewhat altruistic.

[Nat Sakimura]

Follow up needed.

[Kristina Yasuda]

the next steps here are

1/agree on SIOP trust model (#1239);

2/agree if SIOP “collective” is a solution (#1240);

3/write implementation guide for SIOP Chooser (#1212)

and than we should specify how custom url schema works as a invokation mechanism.

[Kristina Yasuda]

Propose to resolve as this has been addressed in PR #25 that has been merged.

[Adam Lemmon]

Agreed @Kristina seems ok to close based on the language introduced in that PR.

[Kristina Yasuda]

Agreed to resolve on 2021-07-22 SIOP special call