[Openid-specs-mobile-profile] Discovery

John Bradley ve7jtb at ve7jtb.com
Tue Nov 18 02:46:22 UTC 2014


Notes on discovery for discussion.

This is an outline of how it could work for servers using accountchooser.com to store the idP preferences in html5 local storage.
Information on the account chooser API is available at accountchooser.net.

I need to flesh out how native apps would work.

Discovery for server based clients

This assumes that the client/RP is registered with a MNO or other entity
that is providing a compliment IdP discovery endpoint. The client has a
client_id and registered redirect_uri.

For server based clients it is highly recommended that they use
AccountChooser.com to perform discovery of the users IdP.

The client must provide a account-status endpoint for accountchooser.com
to POST to.

That endpoint will receive a post from account chooser with the
following information email:  string to send in user hint. providerId: 
This is the issuer (less the https: scheme) Optional displayName: Human
readable name  eg "John Bradley" photoUrl:

The account-status endpoint then replies with:

{"registered":true} means
you know the identity; i.e. you've registered the user and have a
password stored for them on your site that they could log in with.

{"registered":false} means you dont know that identity, so probably you
want them to sign up to get a password on your site.

{"authUri":"IP-uri"} means that for that identity, you rely on an
Identity Provider and the user should be redirected to the provided
IP-uri which will start the appropriate federation protocol with that
IDP. In this case ac.js will dispatch to that URI, and the subsequent
login path depends on how that provider works.

The IP-uri is a client endpoint that takes the paramaters passed to it
and performs Connect discovery by prepending https: to the provided
providerId and using it as the issuer. If the client needs to register
it follows the procedure in the registration spec.

If the user has no registered accounts in account chooser, or elects to
add a new one then they are redirected back to the login page. They can
be presented with a option to add there mobile number.

Selecting this they are redirected to a MNO provided discovery page.
This is a OAuth Authentication request using the client's registered
client_id and the scope "providerId"


The MNO discovers the operator based on: 1 Using headders if the device
is on the carriers network. 2 Using the ip address as a hint (they may
be logging in from a non mobile device so this is only a hint) 3 asking
the user to input a MISDN.

The operator returns a code or token depending on the requested response
type.

The client then performs a get on the MNO's issuer endpoint to retrieve
a JSON object {"iss": "Issuer URI"}

   (yes it would be more efficient to return the iss directly in an
   id_token,  however this is not authentication it is only
   authorization to get the issuer for the user.  Perhaps a special
   id_token with no "sub" using the id_token response_type)

The client then performs Connect Discovery on the issuer URL and
performs dynamic client registration if needed.

The client then performs Connect Authentication.

If the IdP receives an authentication request with no user hint or
id_token hint then it should offer to create a entry for the account in
the browsers html5 local storrage for that account using
accountchooser.com

We could look at optimizations to Account chooser.com that would let the
user directly add their mobile account.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20141117/41452cf3/attachment.p7s>


More information about the Openid-specs-mobile-profile mailing list