<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black;mso-fareast-language:EN-GB">Dear All,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black;mso-fareast-language:EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><i><u><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black;background:white">“…. reached consensus that the standard OpenID Connect flow for authentication is not suitable for transaction authorization, “<o:p></o:p></span></u></i></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%;background:white">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).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%;background:white">We request you to please change the above wording to
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><i><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%;background:white">“Improvements to OpenID Connect flow for contextual authentication(MC Authorisation)
 can be built on the OpenID Framework. Discussed ideas:  <o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%;background:white"><o:p> </o:p></span></i></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><i><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%">1.     Adding extra payload (transaction specific signed JWT) 
 to the ID token so that it will be robust and more secure<o:p></o:p></span></i></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><i><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%">2.     Improving server initiated invocation, through backchannel
 communication between RP and IDP<o:p></o:p></span></i></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><i><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%">3.    
<span style="background:white">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.</span><br>
<span style="background:white">This mechanism might be interesting for other WGs/communities as well (e.g. new Financial WG).</span><o:p></o:p></span></i></p>
<p class="MsoNormal" style="margin-left:18.0pt"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%">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).</span><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%">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”. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%">PS: Any approach, other than OIDC (ex., OAuth 2.0), is not suitable/accepted for Mobile Connect.  <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F4E79;mso-style-textfill-fill-color:#1F4E79;mso-style-textfill-fill-alpha:100.0%">Thank you in advance for understanding !!
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F497D;mso-fareast-language:EN-GB">Best Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F497D;mso-fareast-language:EN-GB">/Siva<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#1F497D;mso-fareast-language:EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-GB">******************************************************************<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;mso-fareast-language:EN-GB">Venkatasivakumar Boyalakuntla | Technical Expert |Personal Data| GSM Association |<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;mso-fareast-language:EN-GB">@:
<a href="mailto:vboyalakuntla@gsma.com"><span style="color:#0563C1">vboyalakuntla@gsma.com</span></a> | @Mob : 00447710020425 | @skype: sivaboyalakuntla |<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;mso-fareast-language:EN-GB">2<sup>nd
</sup>Floor, The Wallbrook Building, 25 Wallbrook, London EC4N 8AF, United Kingdom |<sup><o:p></o:p></sup></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-GB">******************************************************************<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-GB"><img border="0" width="524" height="146" id="Picture_x0020_2" src="cid:image003.jpg@01D1C0DC.635DBA00" alt="Mobile Connect 2016 Signature"></span><span style="mso-fareast-language:EN-GB"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:3.0pt"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black;mso-fareast-language:EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:3.0pt"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black;mso-fareast-language:EN-GB">--------- Original Message ---------<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:3.0pt"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:black;mso-fareast-language:EN-GB">Subject: Openid-specs-mobile-profile Digest, Vol 73, Issue 2<br>
From: openid-specs-mobile-profile-request@lists.openid.net<br>
Date: 6/7/16 2:21 pm<br>
To: openid-specs-mobile-profile@lists.openid.net<br>
<br>
Send Openid-specs-mobile-profile mailing list submissions to<br>
openid-specs-mobile-profile@lists.openid.net<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile<br>
or, via email, send a message with subject or body 'help' to<br>
openid-specs-mobile-profile-request@lists.openid.net<br>
<br>
You can reach the person managing the list at<br>
openid-specs-mobile-profile-owner@lists.openid.net<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Openid-specs-mobile-profile digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Technical Workshop Mobile Connect (Final Minutes)<br>
(Torsten.Lodderstedt@telekom.de)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 7 Jun 2016 15:20:42 +0200<br>
From: <Torsten.Lodderstedt@telekom.de><br>
To: <openid-specs-mobile-profile@lists.openid.net><br>
Subject: [Openid-specs-mobile-profile] Technical Workshop Mobile<br>
Connect (Final Minutes)<br>
Message-ID:<br>
<C78571691D41D54082FAEA979B1445B001C7078DB332@HE110883.EMEA1.CDS.T-INTERNAL.COM><br>
<br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi all,<br>
<br>
please find below the final minutes of the Technical Workshop on Mobile Connect.<br>
<br>
best regards,<br>
Torsten.<br>
<br>
Minutes of the joined Workshop on Mobile Connect between GSMA (CPAS project) and OpenID Foundation (MODRNA WG)<br>
Date: 12/13th of May 2016-05-24<br>
Location: Deutsche Telekom Offices, Darmstadt, Germany<br>
<br>
Attendees:<br>
* Gautam Hazari, Stephen Doyle (partly/remotely), Venkatasivakumar Boyalakuntla (GSMA)<br>
* Michael Engan (T-Mobile US) (partly/remotely)<br>
* Nat Sakimura (NRI, OpenID Foundation)<br>
* John Bradley (Ping Identity, OpenID Foundation)<br>
* Petteri Stenius, Keith Uber (GlobalSign)<br>
* Charles Marais, Philippe Clement (Orange)<br>
* Gonzalo Fernandez Rodriguez (Telefonica)<br>
* Bjorn Hjelm (Verizon)<br>
* J?rg Connotte, Florian Walter, Ulf Linketscher, Zhiyun Ren, Torsten Lodderstedt (Deutsche Telekom)<br>
<br>
(0) Important to note: all changes discussed in this workshop are supposed to be adopted after Mobile Connect Release 2.<br>
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).<br>
<br>
(1) Working Model<br>
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.<br>
<br>
We agreed on the following meetings/ways to collaborate and sync:<br>
- Weekly CPAS/MODRNA liaison call<br>
- MODRNA representatives to attend the CPAS calls (usually J?rg/Gonzalo)<br>
- CPAS representatives may attend MODRNA calls<br>
- Periodical Face 2 Face Workshops - Next to conducted when enough material for MC r3 is available<br>
<br>
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?<br>
<br>
(2) Authentication (MODRNA)<br>
Some modifications/extensions to the authentication spec were discussed:<br>
- How to introduce strength?<br>
- Error/non-error handling in case OP cannot fulfill RP requirements<br>
- LOA4 authentication - add authentication supporting none-repudiation (identity proved subject, transaction needs to be traceable) - today combination if acr value, dtbs & signed data (claim?)<br>
- binding message<br>
o provides verifiable binding between consumption and authentication device<br>
o usually generated by the OP, mandatory to be provided by the RP in the server-initiated case (see below)<br>
o need to have additional parameter (context) to provide RPs option to describe context and purpose of the transaction in free text<br>
- amr<br>
o need to check whether we need other values, e.g. characterizing the security properties of the transport mechanisms<br>
- PCR as login hint<br>
o Give advice on how to implement this feature -> id_token_hint<br>
- additional security considerations/mitigations regarding phishing of OOB authentication<br>
<br>
(3) Transaction Authorization API (MODRNA)<br>
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.<br>
<br>
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.<br>
This mechanism might be interesting for other WGs/communities as well (e.g. new Financial WG).<br>
<br>
(4) Server-initiated Authentication (MODRNA)<br>
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.<br>
To be considered:<br>
- callback/polling needed<br>
- RP potentially knows MSISDN or PPID and wants to enforce it (2nd factor authentication via Mobile Connect)<br>
<br>
(5) Discovery (GSMA/API Exchange)<br>
- Stephen Doyle explained his plans to move discovery and credential management forward.<br>
- 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.<br>
- Mobile Connect Release 2 will also use additional claims in the openid_configuration to proved MC specific meta data.<br>
- Action Item: MODRNA WG to review SDK spec for Mobile Connect Release 2<br>
<br>
(6) Discovery (MODRNA)<br>
- John presented the MODRNA discovery spec<br>
- 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<br>
- 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)<br>
- John mentioned Google's proposal to introduce an alternative discovery service to Android phones via PlayServices<br>
<br>
(7) Credential Management (GSMA/ API Exchange)<br>
- Today, APIgee is effectively managing the credential setup<br>
- Way forward is to adopt software statements/ dynamic client registration<br>
- Learnings:<br>
o developers are getting directed to GSMAs developer portal - they register and setup clients<br>
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<br>
o good starting point for issuing software statements (in a timeframe between 6 month and 1 year from now)<br>
- 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.<br>
<br>
(8) Dynamic Registration (MODRNA)<br>
- Bjorn presented the MODRNA registration spec<br>
- Open: how is lifecycle management of client credentials and software statements supposed to work?<br>
- 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.<br>
<br>
(9) UserInfo/PremiumInfo (CPAS)<br>
- Discussion about the need to have an additional PremiumInfo endpoint<br>
- Use of UserInfo is preferred<br>
- Additional Mobile Connect claims shall be defined in GSMA/MC namespace, short form of claims names shall registered in claims registry<br>
- Action Item: topic will stay within CPAS, MODRNA will provide feedback/review specification<br>
- General question: URLs - use openid or gsma in MODRNA specs? GSMA/MC would make branding people happy<br>
<br>
(10) Attribute Verification (CPAS)<br>
- Topic stays with CPAS<br>
- MODRNA offers to review use cases and existing specs<br>
<br>
(11) Aggregator Integration<br>
- requirements need to be clarified<br>
- There seem to be two use cases:<br>
1. aggregator wants to provide existing SPs with access to Mobile Connect - protocol translation<br>
2. aggregator functions as MC sales channel - does not require hub, issuance of software statements is sufficient<br>
<br>
(12) Account Portability<br>
- 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).<br>
- Note: Microsoft Office 365 recently experienced a similar vulnerability - http://www.economyofmechanism.com/office365-authbypass.html<br>
- Vulnerability can be utilized within MC as well as in general OIDC use cases - It needs to be addressed immediately<br>
- 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<br>
- And here are the first ideas for the alternative design for account portability:<br>
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)<br>
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)<br>
o new MNO associates new account with old profile data<br>
o new MNO responds to login requests with old and new profile data (along with assertion issued by old MNO)<br>
o sector identifier or host name is used to identify existing clients (as old and new client id differ!)<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160607/eee7f5f2/attachment.html><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Openid-specs-mobile-profile mailing list<br>
Openid-specs-mobile-profile@lists.openid.net<br>
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile<br>
<br>
<br>
------------------------------<br>
<br>
End of Openid-specs-mobile-profile Digest, Vol 73, Issue 2<br>
**********************************************************<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p style="font-family: Arial,sans-serif;font-size:11px;color:#999999;"><span lang="EN-US" style="font-family: Arial,sans-serif;color:#999999; mso-fareast-font-family: Arial; mso-fareast-theme-font: minor-latin; mso-bidi-font-family: "Arial"; mso-ansi-language: EN-US; mso-fareast-language: EN-GB; mso-bidi-language: AR-SA">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. </span></p>
</body>
</html>