[Openid-specs-mobile-profile] Moderna Feedback from T-Mobile

Engan, Michael Michael.Engan1 at T-Mobile.com
Mon Jul 2 22:52:20 UTC 2018


Good Morning, I would like to offer up some feedback conversations to the working group on the following:



  1.  Discovery Optimization

Under current Moderna discovery http://openid.net/wordpress-content/uploads/2014/04/draft-mobile-discovery-01.html a Discovery issuer endpoint will respond with an ISS url and login_hint_token. The RP now has multiple calls they will be expected to preform.  (discovery issuer, discovery_ui, discovery issuer, openid_config, Auth request).    In the case of Mobile applications we wish to always optimize the number of calls, as mobile devices while capable of large through put can suffer from high latency.  Furthermore in our ecosystem we have a limited number of participants (MNO's).  Therefore we want to see if the Discovery service (Discovery issuer) would be able to help service the correct carriers openid_configuration up front.

The discovery issuer endpoint would now perform more like
https://discovery.com/.well-known/openid_configuration
and would return the correct carriers openid_configuration (and login_hint_token if appropriate).

The discovery Service would know each MNO's ISS. And therefore would be able to cache each MNO's openid_configuration.
RP's would still need to extract and call each MNO's https protected JWK_URI.
Discovery service would serve openid_configurations according to caching headers, so changes to MNO openid_configurations would still propagate.



  1.  Image discovery integration.
This was discussed a little in the last FAPI discussion in Boston.  The carriers are investigating visual image flows to remove Phishing attack vectors.  Instead of giving a Discovery UI to have a user provide the phone number (&spam pin), the desktop browser would instead be given a visual image possibly representing a transaction id (with enough entropy).  The user would then open up a mobile application to "scan" the image. The application would need to inform the Discovery service about the Login Hint to use, and the appropriate carrier so that the RP can be informed with the login_hint, carrier, and the need for the RP to make a server initiated call (ciba) instead of a  user agent initiated call.

The following is a brainstorm flow.   ( I was informed that I should look at the FAPI visual flows to see what can be reused. ) Note: A major con with this flow would be the  user  has launched the application, but has to wait for the push to be received to continue with the authentication request.  But having the RP inform the discovery service enough OPENID connect parameters for the app to start processing would blur discovery api's from authentication request api's.   Another Option (I believe along FAPI direction) is for the RP to render enough data into the visual image to get the App to start processing the request as a server initiated request. Which would then trigger the POST from the MNO to the registered RP notification endpoint.  We would need to distribute a significant SDK or sample code for this level of RP integration.

[cid:image001.png at 01D4121A.1AF96A70]
[cid:image002.png at 01D4121A.E6756550]



  1.  Context parameter inbound
A third feedback that we have considered is the need for the "context" parameter.  We know at one point it was present in one of the specifications. (core?,moderna?, ciba? ) but we can't find it anymore.   MODERNA has defined the binding_message, But the binding message carries a suggested implementation of rendering something like a pin in both the desktop, and mobile device so the user can confirm the requests are for the same transaction.  The US carriers are looking for the ability to more clearly define a text string that would be rendered to the user within just the mobile device.  The context would be defined for the transaction by the RP.   It would be up to the RP to define authentication or Authorization context messages for the user.  Ie... "Login to continue checking out", or "Do you approve a transfer of $5 to xxxx".

Context would carry a max length limitation, and would be truncated if size exceeds appropriate mobile experience.


  1.  Context parameter outbound
When context is requested, and the Operator includes it in the user experience, then the value would be included in the id_token. (the truncated value the user did see).  GSMA has made a suggestion to look a a combined return attribute but for now the singular context seems more appropriate.




  1.  AKA for Porting
The US carriers have been discussing the AKA parameter for account porting. Ideally an ID_Token can be validated by an RP with only a cached public key for the carrier. Under the current suggestions the RP would now need to make a request to the original carrier with any port_token to complete the validation.  To go back to completely validated by the RP, we would like to see the AKA port token be something like a JWT, or JWE from the original carrier. This way the RP can validate the id_token, and the port_token with cached jwk public keys from both the new and original MNO.
The assertion from the old MNO needs to carry at least

  *   Acknowledgment from the old mno that the user has ported Out of the old MNO
  *   Acknowledgement from the old mno that the user has ported TO the new mno.
  *   Confirmation what the old MNO's pairwise subject was.
  *   Possibly a date of the PORT for use in anti-fraud detection.
It will remain up to the RP to update their subject from the old mno Sub to the new mno's sub once AKA port_token validation is complete.




Michael Engan
Principal Systems Architect,
Authentication, Authorization, & API security
12920 SE 38th Street | Bellevue, WA 98006
Direct 425-383-2268 | Mobile 425-443-3463

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20180702/264105c6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 30686 bytes
Desc: image001.png
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20180702/264105c6/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 69351 bytes
Desc: image002.png
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20180702/264105c6/attachment-0003.png>


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