[oidc4ci] openid_initiate_issuance is an invalid URI scheme
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)
-
-
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.
-
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.
-
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?
-
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.
-
Can mobile apps register multiple intents?
On android this is quite flexible https://developer.android.com/training/app-links/deep-linking, im less sure about iOS
-
PR #226 (cc @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.
-
- changed milestone to Implementer's Draft
-
assigned issue to
-
A couple of things…
- We probably should discourage use of custom schemes where possible
- 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.
-
- changed status to resolved
PR merged and original issue addressed, but discussion on a best custom scheme continues in
#1570 - Log in to comment
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?