[Openid-specs-mobile-profile] Initial Proposal

Connotte, Joerg j.connotte at telekom.de
Tue Aug 5 08:22:17 UTC 2014

Hi Bjorn,

As one of the authors of the initial proposal I would like to thank you for your comments. They all make sense to me. I guess we will restructure the document as soon as we have it converted to the RFC format. I added some remarks inline.


Von: openid-specs-mobile-profile-bounces at lists.openid.net [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von Hjelm, Bjorn
Gesendet: Freitag, 1. August 2014 21:19
An: Torsten Lodderstedt; openid-specs-mobile-profile at lists.openid.net
Betreff: Re: [Openid-specs-mobile-profile] Initial Proposal

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.

Section 2:

·         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.
>JCO: We were aiming at independence of platforms and implementations but we can certainly phrase this better.

·         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.

Section 3:

·         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).
>JCO: We discussed this. We wanted to avoid putting anything into the proposal which could be considered to be not part of the actual Mobile Profile. However I agree that it does help a lot to have some idea how the developer is supposed to interact with the initial MNO (named the 'Developer Operator').

·         Move the statements regarding the scope (for example, in section 3.2) to section 2 as part of the assumptions (or something similar).
>JCO: The reasoning here was to discuss the three extensions we proposed independently (Discovery, registration, authentication).

·         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.

·         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.

·         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.
>JCO: Sorry about that. The url works from our intranet. I try to find a public resource for the ISO/IEC 29115

Section 4

·         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"?
>JCO: It could be either. We didn't want to specify this as a centrally hosted service. It would certainly make sense to have some central authority (e.g. GSMA) to host this service, but it could be hosted by some or all of the participating MNO's.

·         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.)?
>JCO: In some cases this will be the only way to get the MSISDN. If for example the user requests a web page from his pc browser but wants to use Mobile Connect he will have to enter some identification (most likely the MSISDN). In some cases the necessary information for step 1.4 can be acquired automatically (e.g. extracting MCC/MNC from the device). The discussion of the possible scenarios and the appropriate resources will be interesting I guess.

·         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?
>JCO: The easiest way would be to have a map which pairs issuer-url with client credentials as suggested in step 1.7

In general, the document is a good start for the discussion.


-----Original Message-----
From: openid-specs-mobile-profile-bounces at lists.openid.net<mailto:openid-specs-mobile-profile-bounces at lists.openid.net> [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of Torsten Lodderstedt
Sent: Sunday, July 27, 2014 11:14 AM
To: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Subject: [Openid-specs-mobile-profile] Initial Proposal

Hi all,

Deutsche Telekom has prepared an initial proposal for this working group. Please find the document here:

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

"See" you on Tuesday.

best regards,
Openid-specs-mobile-profile mailing list Openid-specs-mobile-profile at lists.openid.net<mailto:Openid-specs-mobile-profile at lists.openid.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20140805/1431fba8/attachment-0001.html>

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