[Openid-specs-mobile-profile] Account porting draft 04

Manger, James James.H.Manger at team.telstra.com
Tue Feb 14 06:20:35 UTC 2017

Draft 04 (14 Feb 2017) of draft-account-porting has been published.
This is a fairly minor update from draft 03. A bigger update is required to switch to encrypting the port_token with the Old OP's public key, instead of with a symmetric client_secret shared by Old OP & New OP.

Xml: draft-account-porting.xml in https://bitbucket.org/openid/mobile/src
Web: https://id.cto.telstra.com/2016/openid/draft-account-porting.html


·         Promoted "Encrypting "port_token"" from a sub-section to its own section

·         Clarified text to addresses Torsten's comments

Specific responses to feedback are provided inline below.

James Manger

From: Torsten.Lodderstedt at telekom.de [mailto:Torsten.Lodderstedt at telekom.de]
Sent: Friday, 18 November 2016 10:22 PM
To: Manger, James <James.H.Manger at team.telstra.com>; openid-specs-mobile-profile at lists.openid.net
Subject: AW: Account porting draft 03

Hi James,

thanks a lot for bringing account porting forward. The draft reads very well!

Here are my comments:

-          Abstract

o   "This specification defines mechanisms to support a user porting from one OpenID Connect Provider to another". I would suggest to modify it to "This specification defines mechanisms to support a user porting her user account from one OpenID Connect Provider to another". This would support a clear distinction between the user herself and her account with a certain OP.

o   Consequently, I would also prefer to use the term "user account" throughout the document where appropriate.
NOT DONE. Porting a "user account" isn't quite correct as a user has separate accounts at the Old OP and New OP (and RPs). We are really creating links between accounts, as opposed to moving an account.

-          Section 3

o   "An Old OP will generally know via other processes when and to whom a user is porting.". That might be true in the case of a mobile operator but not in the general case of an OpenId OP. Moreover, an user might be unable to port her MSISDN but interested to port her login data. I would therefore suggest to modify the text along the following lines "In some cases (such as mobile phone number porting from one MNO to another) the OP knows about an ongoing porting process."

-          Section 4.1

o   I have to admit I'm not sure whether the porting token is always encrypted. Could you please clarify this?
Done. The section (now §4) starts by saying " "port_token" value received by a New OP is encrypted to create an "enc_port_token" value, which is passed to an RP, then back to the Old OP".

o   I'm still not happy with always using the client secret (or a derivate of it) to encrypt the porting token. In my opinion, this facilitates use of shared secrets for client authentication, which we should get rid of. I know we do not directly say that, but I have heard the craziest excuses for people doing weird things in my live. I suggest to at least add asymmetric encryption using the OP's public key.

-          Section 5

o   "Access to the Porting check API requires authentication of the RP." I suggest to add some text explaining the basic idea, something like "The RP uses the same client_id towards the old OP it also uses for the regular OpenId Connect authentication process. This way the old OP is able to collute those interactions and to apply the same client policy (including the respective user id policy)."

o   "The Old OP MUST include the "remove" member when "sub" is present.". You assume there are case where no sub is included in the port check response? When shall this happen and could you state this more explicit?
Done. Description of "sub" member says "This member MAY be absent if the Old OP knows the user never logged in to this RP".

-          Section 6

o   "The New OP to whom the user ported is not identified in the error response for privacy reasons." I think there are security reasons as well. The old OP could try to misguide the RP.

best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170214/50c2e1eb/attachment-0001.html>

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