[oidc4ci] openid_initiate_issuance is an invalid URI scheme

Issue #1500 resolved
Alen Horvat created an issue

openid_initiate_issuance: is not a valid URI scheme
when the browser sees a redirection starting with openid_initiate_issuance://, it interprets it as a relative path

scheme = alpha *( alpha | digit | "+" | "-" | "." )

Proposals:

A) openid://initiate_issuance?…

This approach can be extended for other specs (SIOPv2, …)

B) openid-initiate-issuance://?…

Potential issue: mobile app would need to register multiple schemas.

Comments (11)

  1. Kristina Yasuda

    Proposal A is treated as equivalent to openid:// either in iOS or Android, don’t remember which one but one of them treats ignores what is after ://. So let’s go with Proposal B?

  2. Tobias Looker

    I vote for proposal A why do we need a different URL scheme? In android you can register intents on more than just the URL scheme also not sure about iOS.

  3. Kristina Yasuda

    Openid:// is reserved for SIOPs with specific metadata, and I don’t expect many to use it. So using openid:// in the issuance spec does not really make sense.

  4. Alen Horvat reporter

    Question is, whether we can use the same schema with different endpoints

    e.g.,:

    openid://authorizations (for SIOP, may we’ll need another one for OID4VP?)

    openid://initiate-issuance

    I’m not an expert on mobile platforms so I don’t know which solutions are feasible.

    Supporting questions:

    • Can mobile apps register multiple intents?

  5. Tobias Looker

    So using openid:// in the issuance spec does not really make sense.

    I dont understand why not? The scheme really should just be reserved for any openid supporting application, what they support in terms of SIOP requests vs issuer initiate requests should be communicated in the path. Makes no sense to me to register multiple schemes we would be causing a proliferation at the wrong layer.

  6. David Waite

    I do not know what the initiate-issuance function is so I can’t weigh in there.

    on iOS it is a trade-off since custom uri schemes are discouraged

    • you register for a uri scheme, not a particular path match. You get the entire URI in your app (including fragment), but you won’t have say App A gets invoked on one path and App B gets another
    • You are limited in the number of URI schemes you can invoke as an app
    • You are limited in the number of URI schemes you can register as an app
    • You cannot currently control what app is invoked for a given URI scheme

    They are useful when you have an open-ended list of potential apps which might be invoked, like say any IRC client. They are generally a bad idea if it is a controlled list, such as after metadata has been negotiated.

  7. gffletch

    A couple of things…

    1. We probably should discourage use of custom schemes where possible
    2. I think we probably need a different custom scheme for initiate_issuance to deal with the case where only some Wallet want to handle this case. This will reduce the number of apps that register the same custom scheme which has security and user experience implications.

  8. Log in to comment