[Openid-specs-mobile-profile] Technical Workshop Mobile Connect (Minutes)

Torsten.Lodderstedt at telekom.de Torsten.Lodderstedt at telekom.de
Tue May 24 15:09:29 UTC 2016


Hi all,

please find below the minutes of the Technical Workshop on Mobile Connect.

best regards,
Torsten.

Minutes of the joined Workshop on Mobile Connect between GSMA (CPAS project) and OpenID Foundation (MODRNA WG)
Date: 12/13th of May 2016-05-24
Location: Deutsche Telekom Offices, Darmstadt, Germany

Attendees:
*       Gautam Hazari, Stephen Doyle (partly/remotely), Venkatasivakumar Boyalakuntla (GSMA)
*       Michael Engan (T-Mobile US) (partly/remotely)
*       Nat Sakimura (NRI, OpenID Foundation)
*       John Bradley (Ping Identity, OpenID Foundation)
*       Petteri Stenius, Keith Uber (GlobalSign)
*       Charles Marais, Philippe Clement (Orange)
*       Gonzalo Fernandez Rodriguez (Telefonica)
*       Bjorn Hjelm (Verizon)
*       Jörg Connotte, Florian Walter, Ulf Linketscher, Zhiyun Ren, Torsten Lodderstedt (Deutsche Telekom)

(0) Important to note: all changes discussed in this workshop are supposed to be adopted after Mobile Connect Release 2.
However in the course of the discussion, a severe security issue caused by the current concept for user account portability was identified. OpenID Foundation and MODRNA WG recommend to fix this issue immediately (see below - topic 12).

(1) Working Model
We agreed to explicitly assign any topic to the responsible team, either CPAS or MODRNA. For MODRNA topics, CPAS provides requirements and priorities as well as review feedback. MODRNA topics will be tracked in Bitbucket (https://bitbucket.org/openid/mobile/issues). MODRNA offers to review the results of CPAS topics. Ultimate goal is to reference MODRNA specifications from CPAS specs or directly refer implementers to MODRNA specs.

We agreed on the following meetings/ways to collaborate and sync:
-       Weekly CPAS/MODRNA liaison call
-       MODRNA representatives to attend the CPAS calls (usually Jörg/Gonzalo)
-       CPAS representatives may attend MODRNA calls
-       Periodical Face 2 Face Workshops - Next to conducted when enough material for MC r3 is available

TBD (w/ Steve): Where will discovery/credential management be discusses? Does it make sense to setup a regular meeting between MODRNA and Stephen/API Exchange team?

(2) Authentication (MODRNA)
Some modifications/extensions to the authentication spec were discussed:
-       How to introduce strength?
-       Error/non-error handling in case OP cannot fulfill RP requirements
-       LOA4 authentication - add authentication supporting none-repudiation (identity proved subject, transaction needs to be traceable) - today combination if acr value, dtbs & signed data (claim?)
-       binding message
o       provides verifiable binding  between consumption and authentication device
o       usually generated by the OP, mandatory to be provided by the RP in the server-initiated case (see below)
o       need to have additional parameter (context) to provide RPs option to describe context and purpose of the transaction in free text
-       amr
o       need to check whether we need other values, e.g. characterizing the security properties of the transport mechanisms
-       PCR as login hint
o       Give advice on how to implement this feature -> id_token_hint
-       additional security considerations/mitigations regarding phishing of OOB authentication

(3) Transaction Authorization API (MODRNA)
We reached consensus that the standard OpenID Connect flow for authentication is not suitable for transaction authorization. Therefore the mechanism for this use case currently specified  in the Mobile Connect Profile is not suitable as well. Nevertheless, a reasonable solution can be built within the OpenID framework.
The MODRNA WG will propose a reasonable mechanisms to perform transaction authorizations via OpenID. The idea is to define an additional OpenID Connect endpoint (like UserInfo) for this purpose. Access to this endpoint is protected using Access Tokens issued for a certain scope value. How the access token is obtained (client credentials, web flow, ...) is out of scope. The RP uses this endpoint via server 2 server communication to initiate transaction authorization processes. Potentially, the user account to be asked for authorization must be identified via a dedicated parameter. Alternatively, it is implicitly defined by the access token.
This mechanism might be interesting for other WGs/communities as well (e.g. new Financial WG).

(4) Server-initiated Authentication (MODRNA)
The MODRNA WG will propose a reasonable mechanisms to perform authentication in cases, where no user agent is available and the authentication process needs to initiated via server 2 server communication. Use cases are for example user authentication in the context of a call center call. The idea is to introduce an extension to the token endpoint (TBD: new grant type or JWT bearer assertion), which is used in conjunction with the standard scope value "openid" and potentially other OIDC scope values and parameters to initiate the authentication. The authentication process is conducted out of band using the same mechanisms the ID gateway uses for the standard Mobile Connect/OpenID Connect authentication flow via browser redirect.
To be considered:
-       callback/polling needed
-       RP potentially knows MSISDN or PPID and wants to enforce it (2nd factor authentication via Mobile Connect)

(5) Discovery (GSMA/API Exchange)
-       Stephen Doyle explained his plans to move discovery and credential management forward.
-       Starting with the upcoming Release 2 of Mobile Connect, the SDKs will prefer OIDC openid_configuration over the endpoint URLs provided by API Exchange. We pointed out that API exchange should return the issuer URL and the client/SDK should build the actual URL to obtain openid_configuration the way described in the respective OIDC spec.
-       Mobile Connect Release 2 will also use additional claims in the openid_configuration to proved MC specific meta data.
-       Action Item: MODRNA WG to review SDK spec for Mobile Connect Release 2

(6) Discovery (MODRNA)
-       John presented the MODRNA discovery spec
-       He raised the question whether there is a need to protect the discovery service. The overall flow could greatly be simplified be just using a direct interaction between client and discovery service instead of redirect based protocol
-       Note: native apps cannot be reliably be authenticated -> no protection for abuse of discovery anyway (even if redirect based protocol is used in conjunction with client secrets)
-       John mentioned Google's proposal to introduce an alternative discovery service to Android phones via PlayServices

(7) Credential Management (GSMA/ API Exchange)
-       Today, APIgee is effectively managing the credential setup
-       Way forward is to adopt software statements/ dynamic client registration
-       Learnings:
o       developers are getting directed to GSMAs developer portal - they register and setup clients
o       if the app is promoted into production status, an email is generated, which is sent to all operators and asks them to setup this app
o       good starting point for issuing software statements (in a timeframe between 6 month and 1 year from now)
-       openid_configuration could be used to provide (interested) clients with the registration endpoint of an OP. So interested deployments could start to evaluate the new approach starting with the availability of the new Mobile Connect version 2.

(8) Dynamic Registration (MODRNA)
-       Bjorn presented the MODRNA registration spec
-       Open: how is lifecycle management of client credentials and software statements supposed to work?
-       John: Revocation of software statement could be handled by a central service provided by OIX (based on block chaining?) - Advantage: issuer of a software statement does not need to provide 24/7 service for statement revocation checks.

(9) UserInfo/PremiumInfo (CPAS)
-       Discussion about the need to have an additional PremiumInfo endpoint
-       Use of UserInfo is preferred
-       Additional Mobile Connect claims shall be defined in GSMA/MC namespace, short form of claims names shall  registered in claims registry
-       Action Item: topic will stay within CPAS, MODRNA will provide feedback/review specification
-       General question: URLs - use openid or gsma in MODRNA specs? GSMA/MC would make branding people happy

(10) Attribute Verification (CPAS)
-       Topic stays with CPAS
-       MODRNA offers to review use cases and existing specs

(11) Aggregator Integration
-       requirements need to be clarified
-       There seem to be two use cases:
1.      aggregator wants to provide existing SPs with access to Mobile Connect - protocol translation
2.      aggregator functions as MC sales channel - does not require hub, issuance of software statements is sufficient

(12) Account Portability
-       Current concept forces RPs to ignore "iss" claim and select user accounts based on "sub" claim only. This creates a huge security risk since ANY IDP in an ecosystem (like Mobile Connect) can assert identities of any other attached IDP! It violates the fundamental OpenID concept of scoped userid (authority).
-       Note: Microsoft Office 365 recently experienced a similar vulnerability - http://www.economyofmechanism.com/office365-authbypass.html
-       Vulnerability can be utilized within MC as well as in general OIDC use cases - It needs to be addressed immediately
-       MODRNA proposal: stick to OpenID concept of scoped identity for Mobile Connect Release 2 and adopt different concept for account portability, MODRNA will support development of alternative design
-       And here are the first ideas for the alternative design for account portability:
o       migrate scoped user ids using a protocol similar to OpenID 2.0 migration protocol (http://openid.net/specs/openid-connect-migration-1_0.html)
o       old MNO issues id tokens containing old sub (PCR) along with destination MNOs issuer URL -> used by destination MNO to prove migration of PCR from old MNO (old authority)
o       new MNO associates new account with old profile data
o       new MNO responds to login requests with old and new profile data (along with assertion issued by old MNO)
o       sector identifier or host name is used to identify existing clients (as old and new client id differ!)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160524/26a5b2ea/attachment.html>


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