[Openid-specs-mobile-profile] Account porting draft 03
Torsten.Lodderstedt at telekom.de
Torsten.Lodderstedt at telekom.de
Fri Nov 18 11:22:29 UTC 2016
thanks a lot for bringing account porting forward. The draft reads very well!
Here are my comments:
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.
- 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?
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?
- 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.
Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von Manger, James
Gesendet: Sonntag, 13. November 2016 20:41
An: openid-specs-mobile-profile at lists.openid.net
Betreff: [Openid-specs-mobile-profile] Account porting draft 03
Draft 03 (13 Nov 2016) of draft-account-porting has been published.
Xml: draft-account-porting.xml in https://bitbucket.org/openid/mobile/src
* New section 1.2 "Porting flow" provides an overview of the porting message flow.
* Clearer language about the "aka" (also-known-as) member, including that "enc_port_token" is opaque for RPs
* Rename "oidc-porting" to "openid-connect-porting" - it takes more bytes, but is more self-explanatory
* New OP MUST (not just SHOULD) include sector_id (or host of redirect_uri)
* "remove": true/false member in Porting check API response - telling RP to remove (or keep) Old OP's sub on account; distinguishing a "port" (moved from Old OP to New OP) vs a "link" (allow login from either OP)
* "user_ported" error code for authorization endpoint - so RP knows to redo OP Discovery for this user
Thanks to Torsten for the feedback that led to many of these changes.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-mobile-profile