Announced OAuth-J, OAuth Optical Transport Profile for network resilience. Applying virtual currency technology.

On April 2018, 4, the OAuth Foundation Japan (OAuth-J) announced that it will begin developing a new OAuth profile, the OAuth Optical Transport Profile (OAuth OTP), that also supports Internet isolation.

OAuth [RFC6749] is an API protection technology widely used by mobile phone companies, banks, airlines, media, government agencies, etc., not to mention GAFAM (Google, Apple, Facebook, Amazon, Microsoft), and is a core technology of API economy. However, since it relies on HTTPS as a communication protocol (transport), in an environment where Internet isolation has been implemented due to the recent trend of network resilience, the client is located on the internal network and the authorization server is located on the Internet side.¹There was a drawback in that processing could not be performed if servers were distributed across multiple disconnected networks, etc. Therefore, there was a risk that strengthening the network would leave it behind in the API economy.

To solve this problem, OAuth OTP introduces an optical transport to be used between the internal network and the external network instead of HTTPS. Specifically, the authorization request and response are printed on paper using the two-dimensional code technology used in paper wallets, which are often used to increase the security of virtual currency transactions using blockchains, and are processed by reading them with an optical reader connected to the opposite network. When converting the request into a two-dimensional code, a 4-digit unique ID called a nonce is generated separately and included in it.², and include the same ID in the response³This makes it possible to perform code injection attacks.⁴In addition, because the paper is read by an optical reader, unlike the method using a USB memory stick, there is no risk of contamination in the supply chain.⁵BadUSB via⁶It also responds to attacks.

Prior to this announcement, this proposed standard was scheduled to be submitted to the IETF as an ID during fiscal year 2017. However, according to editor Nat Sakimura, "Just because it's April Fool's Day doesn't mean we can allow them to tell a malicious lie, such as that fiscal year 2017 has ended," and so as of today, the submission has not yet been made.

Nov Shintake, Executive Director of OAuth-J, expressed his expectations regarding this matter as follows:

"This proposed standard is a decisive step that will save many Japanese organizations from being left behind in the API economy, and its benefits will not only be felt in Japan, but will also be shared with many other organizations in Asia and elsewhere who follow its example. For this reason, OAuth-J has submitted a proposed standard to the Universe Standardization Organization and hopes to obtain a USO number. We believe that a number in the 800 range would be preferable, but given the current state of number allocation, it is unclear whether our wishes will be granted."

Addendum: April 4

Since it seems to be good manners to reveal the secret on 4/2, I'll write about it here, but I think this works fine. It's still worth considering whether it can be used for anything, though. By the way, the QR code in the diagram is really an OAuth Request/Response. However, it is a Code flow. If you actually use it on a separate network, the Code flow would require one more round trip, so it's not realistic. It should be made implicit.

In that case, the Access Token will be printed in plain text on the QR code. Naturally, security cameras will be installed in places where such work is done, so there is a risk that the Access Token will be leaked from the images and used. Therefore, the Access Token must be encrypted or sender constrained. The former will not be covered by RFC6749, and there may be an impact if it is leaked for other reasons, so the latter is better. In that case, the Client can register its own Public Key in the AS in advance, put the keyhash in the AT, and use it in combination with MTLS. In that case, if the resource is in the internal network, there will be no need to connect to an external network. If the resource is in an external network, it would be more realistic to obtain the data on the external network and then bring the data into the internal network before working on it.

Also, when printing QR codes, I think the expiration date should be printed human readable, and then discarded or archived.

1. If the resource being handled is personally identifiable information [JIS X 9250], the individual is basically on the Internet side, so the authorization server must be on the Internet side.
2. It uses state variables, so it is compatible with existing OAuth.
3. Automatically met by RFC6749.
4. An attack that takes advantage of a weak binding between authorization requests and responses by replacing an authorization code with a different one obtained separately. Also known as a cut-and-paste attack.
5. This is an attack that replaces a product, installs software, or reduces its performance in adverse environments during the supply chain from when the product leaves the factory to when it is delivered to the user. Warehouses and truck beds are common targets. There have been cases where hardware wallets for virtual currency purchased through Amazon have been attacked in this way, resulting in the loss of all virtual currency. This is a particularly big problem with military supplies, and the US Department of Defense requires in the National Defense Authorization Act to reduce the risk by purchasing directly from manufacturers without going through distribution channels.
6. This attack was presented at Black Hat USA 2014. It uses the USB firmware to trick connected devices, making it possible to extract data and perform other actions.