rename from "Static Discovery" a set of SIOP metadata tied to `openid:`

[Kristina Yasuda]

inspired by a discussion in #226

Is there a need for a mandatory to implement custom URL scheme (openid:), that guarantees minimum interop between issuer-wallet-verifier? I am not convinced it is a good idea because issuer/verifier when using this costom scheme will have to know which algorithms and other parameters to use.

Original intent was openid: not to be widely used in SIOP v2 - and for profiles to define their own custom url schemes with metadata (algs, etc.) for interoperability.

(the issue used to be called: “decouple openid: custom URL scheme from Static metadata?“)

[Thomas Bellebaum]

Thinking in terms of wallets:
If you do not have a “default URI”, it becomes hard to have a “generic default wallet” which can hold a covid certificate, your ID from your library, and your university diploma at the same time, since those are very unlikely to agree on any form of common “profile” other than the presentation protocol itself.
The way I interpreted the static metadata authorization_endpoint was as a generic endpoint to redirect a request to if “I just want the credential (and/or PoP of some identity)”, without mandating a specific app or profile. In other terms, as a “device wallet”, which may either be a wallet implemented by the OS or browser or just the user’s chosen default wallet.

Why?
Today, users are very hesitant to use e.g. multiple messengers. That the right app will be invoked by a request does not help much either (works with messengers too; you still get a notification from the right app, which will open if you tap on it). So having a dedicated app for each “profile” might be seen as inconvenient to the point of hindering adoption. What we need to counteract this are incentives to provide interoperability, and having a custom URI for each “profile” might be counterproductive there. (Of course, different URIs for application specific purposes are still possible → dynamic metadata)

Of course, a default URI might not need to have a custom scheme, and in fact early wallet integration would be much easier with just HTTP, but for security it may also be beneficial to use a scheme for which not any random app can register a handler.

[Michael Jones]

The default metadata values were always, at best, a simple expedient, with known limitations. I could be convinced that the time for it has past, provided there are other adopted mechanisms that can replace it.

[Tobias Looker]

IMO what the static metadata document really represents is a set of agreed choices that every conforming SIOP based OP conforms to, which means when a RP goes to execute a request to a SIOP based OP, they know at a minimum what should be supported by the SIOP that is registered to handle the openid:// based url. The set of decisions made by the SIOP spec that at present defines this static metadata, doesn’t need to be recorded and published as metadata document. Instead RP’s implementing support for SIOP could just codify these same static rules into their implementation, because they are after all static.

[David W Chadwick]

@ Tobias. I agree with you. The static metadata represents the minimal subset of features that all implementations must support.

[Kristina Yasuda]

@Thomas the problem is that unless we make openid:// and a set of metadata tied to it, it cannot serve as a fallback option you are describing (one thing that opens when everything else fails). realistically what is happening in the market now, is multiple implementations that use different set of metadata still use the same “openid“ which defeats the purpose.

In Aug-11 SIOP call, we agreed to position metadata tied to “openid:“ as a profile defined by this spec (one of many profiles) that implementers who have absolutely no alternative can use

[Kristina Yasuda]

PR merged