Currently, the mobile client does the following when a patron taps the 'login' button:

• Append  /loans to the circulation manager URL and send a GET request to get the patron's loans feed. If the credentials are incorrect, this request fails. Otherwise, the circulation manager cranks out a list of loans which – this is the crucial point – includes the patron's Short Client Token.
• Use the Short Client Token to register the device with Adobe. This will create or retrieve an Adobe ID for the patron.

The first problem is that hard-coded /loans URL. This works for circulation managers but it won't work in general. The second problem is that getting the loans feed can take a long time and isn't necessary just to perform the function the user thinks of as "logging in". What we really need is that Short Client Token.

So, a new plan:

• Make a HEAD request to the circulation manager root URL. The result will link to an Authentication For OPDS document.
• GET the Authentication For OPDS document. This will have a link to the 'bookshelf' feed and a link to the profile document.
• If you want, start an authenticated GET request to the bookshelf feed. This will let you populate the patron's bookshelf in the background.
• Send an authenticated GET request to the profile document. If the credentials are incorrect, this request fails. Otherwise, the profile document will contain a Short Client Token for the authenticated patron.
• Use the Short Client Token to register the device with Adobe. This will create or retrieve an Adobe ID for the patron.

If there's no Authentication For OPDS link in the root URL, send a GET request to the root URL and try to find a 'profile' or 'bookshelf' link in the resulting feed.