<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri" size="2"><span style="font-size:11pt;">
<div>Torsten,</div>
<div>The below comments are based on my initial review and attempt to understand the different aspects of the problem statement and proposal. Some of the comments may be more structural or editorial but would help in reviewing the proposal.</div>
<div> </div>
<div> </div>
<div>Section 2:</div>
<div> </div>
<ul style="margin:0;padding-left:36pt;">
<li>Though I understand the intent of the statement the Mobile Profile "must be easy to implement for developers" the term "easy" is hard to quantify. I would suggest using some other reference such as minimize complexity (in terms of implementation) or independent
of platforms (or something similar) to be more specific about what the goal is. It may seems trivial but the more specific we're the easier (based on my experience) it'll be once we start reviewing and assessing the impact of the technical options.</li></ul>
<div> </div>
<ul style="margin:0;padding-left:36pt;">
<li>Add a sub-section to define the actors (or terminology used to define the actors) used in the problem statement in Section 3. It's especially important when applying different scenarios (that may exemplify different relationship between the different actors)
used in section 3.</li></ul>
<div> </div>
<div>Section 3:</div>
<div> </div>
<ul style="margin:0;padding-left:36pt;">
<li>Add some basic picture to describe the different scenarios and flows of information (such as the use case of dynamic client registration with multiple MNOs where the initial MNO is the "Developer Operator"). I can see that this will be very important to
understand when we start addressing cross-operator or other boundaries that have different business, regulatory, and/or technical dynamics when things can start getting very complex (and not easy to implement).</li></ul>
<div> </div>
<ul style="margin:0;padding-left:36pt;">
<li>Move the statements regarding the scope (for example, in section 3.2) to section 2 as part of the assumptions (or something similar).</li></ul>
<div> </div>
<ul style="margin:0;padding-left:36pt;">
<li>I had a similar question as Tim on the requirements for Software Statement but the justification for this may come further as the problem statement is further detailed and the technical options available become more clear so I'll leave that question open
for now.</li></ul>
<div> </div>
<ul style="margin:0;padding-left:36pt;">
<li>Maybe trivial but I would change the term “keen” (section 3.3) to “should be able” to better exemplify the intent of the RP and then specific the conditions for when this could apply. I would also make the assumption that a LoA would’ve to be the foundation
for the type of authentication method and the question is more about what reference to use for LoA.</li></ul>
<div style="padding-left:36pt;"> </div>
<ul style="margin:0;padding-left:36pt;">
<li>The URL for [6] results in “Missing the document identifier” both when trying to access this document from the reference section of the document and attempting to access the document from inside OASIS site. </li></ul>
<div> </div>
<div>Section 4</div>
<div> </div>
<ul style="margin:0;padding-left:36pt;">
<li>In step 1.4, is the Operator Discovery Services, a clearing-house (‘resolving’ the request and providing the re-direct functionality) or the same as the “Developer Operator”? </li></ul>
<div> </div>
<ul style="margin:0;padding-left:36pt;">
<li>Is the assumption for the statement that the user types the MSISDN (for step 1.7) that the web application/device isn’t associated with the actual mobile subscription and deson’t have the MSISDN stored (multi-device scenario, wi-fi only device, non-mobile
end-pint, etc.)?</li></ul>
<div> </div>
<ul style="margin:0;padding-left:36pt;">
<li>In step 1.10, how would the client check if the OpenID Provider information is already known? Another way to ask this question is what are the assumptions for this to be a true statement?</li></ul>
<div> </div>
<div> </div>
<div>In general, the document is a good start for the discussion.</div>
<div> </div>
<div>BR,</div>
<div>Bjorn</div>
<div> </div>
<div>-----Original Message-----<br>

From: openid-specs-mobile-profile-bounces@lists.openid.net [<a href="mailto:openid-specs-mobile-profile-bounces@lists.openid.net">mailto:openid-specs-mobile-profile-bounces@lists.openid.net</a>] On Behalf Of Torsten Lodderstedt<br>

Sent: Sunday, July 27, 2014 11:14 AM<br>

To: openid-specs-mobile-profile@lists.openid.net<br>

Subject: [Openid-specs-mobile-profile] Initial Proposal</div>
<div> </div>
<div>Hi all,</div>
<div> </div>
<div>Deutsche Telekom has prepared an initial proposal for this working group. Please find the document here: </div>
<div><a href="http://openid.bitbucket.org/Mobile_Profile_initial_draft_016.pdf">http://openid.bitbucket.org/Mobile_Profile_initial_draft_016.pdf</a></div>
<div> </div>
<div>The main purpose of this document is to facilitate the discusion within the group about the challenges with have to cope with and the assumptions we base our work upon. It also sketches a potential solution (which is certainly open for discussions).</div>
<div> </div>
<div>"See" you on Tuesday.</div>
<div> </div>
<div>best regards,</div>
<div>Torsten.</div>
<div>_______________________________________________</div>
<div>Openid-specs-mobile-profile mailing list <a href="mailto:Openid-specs-mobile-profile@lists.openid.net">Openid-specs-mobile-profile@lists.openid.net</a></div>
<div><a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a></div>
<div> </div>
</span></font>
</body>
</html>