Overview#Private URI Scheme is defined in RFC 7595 in Section 6 as:
Unregistered schemes can cause problems if use is not limited to a private environment within a single organization since the use could leak out beyond the closed environment. Even within a closed environment, other colliding uses of the same scheme name could occur. As such, a unique namespace MUST be used and 'provisional' registration is strongly encouraged (unless the scheme name is constructed from a DNS Domain name), as discussed in Section 3.8.SHOULD use a prefix based on their domain name, expressed in reverse order. For example, a URI Scheme name of:
Private URI Scheme are not real useful!#
Getting a trusted Authorization Server to say you are Tripit or some trusted client when you are really a bad guy is becoming a real problem. This is however not directly connected to the client mix up issue, and needs to be addressed separately. One thing we added to dynamic client registration was a software statement that can lock down redirect URI for a given client. In the case of Mobile Connect for Mobile network operators the proposal is to have a trusted registration authority that validates clients and issues them software statements to register at individual AS. Validating the developer/client will probably need to be a business process, more stringent than just getting a developer account based on an email address. One possibility might be to check if the redirect URI has a EV certificate indicating the organization, or trust frameworks set up to register clients for conformance with European data protection laws (yes with safe harbour going away something like that might be required by AS to keep on the good side of the law. Germany did take a run at this once, but it did not work for the internet in a practical way) The biggest issue will probably be identifying native apps. Custom scheme redirects are not real useful. On iOS and Android (beta) there are now ways for an app to claim a https: URI that is controlled by the developer. https://tools.ietf.org/html/draft-ietf-oauth-native-apps-00#page-9 That in combination with software statements might be a useful way to identify the client and display something useful at the AS. We need to do more work on this in my opinion. John B.