LDAPWiki: Private URI Scheme

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.

RFC 7595 Section 3.8#

Some organizations desire their own namespace for URI scheme names for private use (see Section 6). In doing so, it is important to prevent collisions and to make it possible to identify the owner of a private-use scheme. To accomplish these two goals, such organizations SHOULD use a prefix based on their domain name, expressed in reverse order. For example, a URI Scheme name of:

com.example.mything

might be used by the organization that owns the example.com domain name. Care must be taken, however, if the organization later loses the domain name embedded in their scheme names since DNS Domain name registrations are not permanent. To associate the Private URI Scheme name with the original organization, the Private URI Scheme can be registered using the registration procedure in RFC 7595 Section 7.

Private URI Scheme are not real useful!#

Private URI Scheme has no requirement that the Private URI Scheme is a DNS Domain under the Application developer's control. Therefore Claimed Https Scheme URI Redirection is RECOMMENDED

John Bradley on the OAuth 2.0 mailing list:

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.

More Information#

There might be more information for this subject on one of the following: