[Openid-specs-mobile-profile] Moderna Feedback from T-Mobile: AKA for porting

Manger, James James.H.Manger at team.telstra.com
Tue Jul 10 14:54:13 UTC 2018

Hi Michael,

"The assertion from the old MNO" actually needs to be many assertions - one per RP - since it carries "the old MNO's pairwise subject" (ie a RP-specific "sub").
So if a user has accessed 100 RPs, then during porting the old MNO need to generate, sign and send 100 JWTs, and the new MNO need to store these. Would we need limits?

An old MNO might not know all the RPs a user has visited. It isn't strictly necessary to record this if the per-RP pairwise sub is derived whenever a login to that RP occurs. That would make it basically impossible to generate all the assertions at the porting time.

Another disadvantage of generating all the per-RP assertions up front (at port time) is the privacy issue. The new MNO learns the user's entire history, even if the user never intends to visit some of the old RPs ever again.

Assertions that are generated at port time, but not consumed by an RP until the user next signs in to that RP (perhaps months later), means we need longer-term keys and revocation support. In contrast to the current scheme that can operate with frequently-rotated short-term no-revocation-needed keys.

James Manger

From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of Engan, Michael
Sent: Tuesday, 3 July 2018 8:52 AM
To: Openid-specs-mobile-profile <openid-specs-mobile-profile at lists.openid.net>
Subject: [Openid-specs-mobile-profile] Moderna Feedback from T-Mobile

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


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/20180710/eb0564fe/attachment.html>

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