[Openid-specs-mobile-profile] Openid-specs-mobile-profile Digest, Vol 73, Issue 2

Venkatasivakumar Boyalakuntla vboyalakuntla at gsma.com
Tue Jun 7 15:48:17 UTC 2016


Dear All,

".... reached consensus that the standard OpenID Connect flow for authentication is not suitable for transaction authorization, "


I am sorry to say that, the above sentence in the minutes which created much confusion for R2.  It is very clearly said that R2 release is void. We would like to have following wording to avoid confusion.  As such, authentication flow of OIDC is very well suited to contextual authentication (MC Authorisation).

We request you to please change the above wording to

"Improvements to OpenID Connect flow for contextual authentication(MC Authorisation) can be built on the OpenID Framework. Discussed ideas:


1.     Adding extra payload (transaction specific signed JWT)  to the ID token so that it will be robust and more secure

2.     Improving server initiated invocation, through backchannel communication between RP and IDP

3.     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).


Currently, there is no way in the protocol to specify "what" the user shall authorize and to communicate back whether the user actually authorized it. All the OIDC flow gives you is the information whether there had been successfully been authenticated (Courtesy Torsten).

We have clearly mentioned during workshop "Mobile Connect Authorisation "is marketing term for "Contextual Authentication OR approval process".  Yes, I agree that "what" is not available in the current OpenID Connect specification, whereas in Mobile Connect Profile already has additional parameters ("context", client name and binding_message) to fulfil this requirement and agreed in CPAS. Yes, alignment needs to happen between MC Profile v1.2 and OpenID connect specs.

The first sentence in the minutes clearly says that the current solution is not suitable.  This is creating much confusion to all participants and for R2 activities.   Moreover, only one discussed approach "adding an additional end point"  is  mentioned. We have also discussed "additional payload ( signed JWT) in the ID Token" along with "server initiated communication through backchannel".

PS: From GSMA point of view, we have not come to consensus OR agreed on the approach we will take it forward for Mobile Connect.  Based on our future discussions, together we can select the optimal solution by aligning with OIDC PROTOCOL.

PS: Any approach, other than OIDC (ex., OAuth 2.0), is not suitable/accepted for Mobile Connect.

Thank you in advance for understanding !!

Best Regards,
/Siva

******************************************************************
Venkatasivakumar Boyalakuntla | Technical Expert |Personal Data| GSM Association |
@: vboyalakuntla at gsma.com<mailto:vboyalakuntla at gsma.com> | @Mob : 00447710020425 | @skype: sivaboyalakuntla |
2nd Floor, The Wallbrook Building, 25 Wallbrook, London EC4N 8AF, United Kingdom |
******************************************************************
[Mobile Connect 2016 Signature]


--------- Original Message ---------
Subject: Openid-specs-mobile-profile Digest, Vol 73, Issue 2
From: openid-specs-mobile-profile-request at lists.openid.net
Date: 6/7/16 2:21 pm
To: openid-specs-mobile-profile at lists.openid.net

Send Openid-specs-mobile-profile mailing list submissions to
openid-specs-mobile-profile at lists.openid.net

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
or, via email, send a message with subject or body 'help' to
openid-specs-mobile-profile-request at lists.openid.net

You can reach the person managing the list at
openid-specs-mobile-profile-owner at lists.openid.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Openid-specs-mobile-profile digest..."


Today's Topics:

1. Technical Workshop Mobile Connect (Final Minutes)
(Torsten.Lodderstedt at telekom.de)


----------------------------------------------------------------------

Message: 1
Date: Tue, 7 Jun 2016 15:20:42 +0200
From: <Torsten.Lodderstedt at telekom.de>
To: <openid-specs-mobile-profile at lists.openid.net>
Subject: [Openid-specs-mobile-profile] Technical Workshop Mobile
Connect (Final Minutes)
Message-ID:
<C78571691D41D54082FAEA979B1445B001C7078DB332 at HE110883.EMEA1.CDS.T-INTERNAL.COM>

Content-Type: text/plain; charset="iso-8859-1"

Hi all,

please find below the final 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, but a reasonable solution can be built within the OpenID framework.

The MODRNA WG will propose such a 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/20160607/eee7f5f2/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Openid-specs-mobile-profile mailing list
Openid-specs-mobile-profile at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile


------------------------------

End of Openid-specs-mobile-profile Digest, Vol 73, Issue 2
**********************************************************


This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160607/2566d248/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 10950 bytes
Desc: image003.jpg
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160607/2566d248/attachment-0001.jpg>


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